nextcloud-init-sync.lock fails integrity check after 29->30

[dkadioglu]

After I have upgraded from 29.0.6 to 30, I see an error regarding a failed integrity check for nextcloud-init-sync.lock:

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results
=======
- core
    - EXTRA_FILE
        - nextcloud-init-sync.lock

Raw output
==========
Array
(
    [core] => Array
        (
            [EXTRA_FILE] => Array
                (
                    [nextcloud-init-sync.lock] => Array
                        (
                            [expected] => 
                            [current] => cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
                        )

                )

        )

)

Deleting the file and restarting does not help.

My compose file:

volumes:
  nextcloud:
    name: nextcloud
    external: true
  apps:
    name: apps
    external: true
  config:
    name: config
    external: true
  data:
    name: data
    external: true
  db:
    name: nextcloud-compose_db
    external: true
services:
  db:
    image: mariadb:10.6
    container_name: nextclouddb
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    restart: unless-stopped
    ports:
      - 127.0.0.1:3307:3306
    volumes:
      - ./mysql/data:/var/lib/mysql
      - "/etc/timezone:/etc/timezone:ro"
      - "/etc/localtime:/etc/localtime:ro"
      - ./mysql/conf.d:/etc/mysql/conf.d
    environment:
      - MYSQL_ROOT_PASSWORD=anonymized
      - MYSQL_PASSWORD=anonynized
      - MYSQL_DATABASE=anonymized
      - MYSQL_USER=anonymized
      - MARIADB_AUTO_UPGRADE=1
    labels:
      - wud.watch.digest=true
      - wud.tag.include=^10.6$$
  app:
    image: nextcloud
    container_name: nextcloud
    ports:
      - 127.0.0.1:8080:80
    links:
      - db
    volumes:
      - ./data:/var/www/html
      - "/etc/timezone:/etc/timezone:ro"
      - "/etc/localtime:/etc/localtime:ro"
    restart: unless-stopped
    environment:
    #  - REDIS_HOST=redis
      - PHP_MEMORY_LIMIT=2560M
    # Unix socket modifications
    # Add shared volume from Temporary busybox container
    volumes_from:
      - tmp
  redis:
    image: redis:alpine
    container_name: redis
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
      # Unix socket modifications
      - ./redis.conf:/etc/redis.conf
    # Run redis with custom config
    command: redis-server /etc/redis.conf
    # Run as a member of the www-data GID 33 group but keep redis uid as 999
    user: "999:33"
    depends_on:
      - tmp
    # Add shared volume from Temporary busybox container
    volumes_from:
      - tmp
  previews_hpb:
    image: h2non/imaginary
    ports:
      - "127.0.0.1:8088:8088"
    restart: unless-stopped
    environment:
      - PORT=8088
  #Temporary busybox container to set correct permissions to shared socket folder
  tmp:
    image: busybox
    command: sh -c "chown -R 33:33 /tmp/docker/ && chmod -R 770 /tmp/docker/"
    volumes:
      - /tmp/docker/
    labels:
      - wud.watch=true

My system config:

{
    "system": {
        "debug": false,
        "default_phone_region": "DE",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "overwriteprotocol": "https",
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "dbindex": 0,
            "timeout": 1.5
        },
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "30.0.0.14",
        "installed": true,
        "maintenance": false,
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "tls",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "loglevel": 2,
        "theme": "",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "mysql.utf8mb4": true,
        "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***",
        "app_install_overwrite": [
            "issuetemplate",
            "event_update_notification",
            "documentserver_community",
            "onlyoffice",
            "spreed",
            "whiteboard",
            "bookmarks",
            "richdocumentscode",
            "richdocuments",
            "integration_whiteboard",
            "cookbook",
            "collectives"
        ],
        "enabledPreviewProviders": [
            "OC\\Preview\\MP3",
            "OC\\Preview\\TXT",
            "OC\\Preview\\MarkDown",
            "OC\\Preview\\OpenDocument",
            "OC\\Preview\\Krita",
            "OC\\Preview\\Imaginary"
        ],
        "preview_imaginary_url": "***REMOVED SENSITIVE VALUE***",
        "maintenance_window_start": "1"
    }
}

If further info is needed, please ask.

[jaycedk]

I'm seeing the same. Delete file, restart docker, same error again. Looking in the file system the same nextcloud-init-sync.lock is recreated at docker start up.

[jaycedk]

I fixed this by changing file permissions. From root to Nobody OS unRaid.

[BarBaar44]

Confirming!

Changing ownership to www-data doesn't help here..

OS: Fedora 40

[dkadioglu]

Changing ownership to nobody as well as www-data doesn't work for me.

[marco-calautti]

I also have the same issue, but changing owner to nobody did not fix the problem.

[jaycedk]

I did this in unRaid. Restarted docker and got this result. Not sure if this is safe to do 😉

[joshtrichards]

Reproduced, but here in the image we haven't changed anything related to this lately.

https://github.com/nextcloud/docker/blob/30b570f0b553736d63dc63cf487ff1e5e5331474/docker-entrypoint.sh#L277

This file has always been ignored by the integrity checker (and still is in <30) - which was always a bit surprising to me - so perhaps something has changed upstream.

Possibly nextcloud/server#46174 changed things.

[joshtrichards]

Awhile ago, before we switched to using flock we used to clean-up the lock file after we were done with it:

https://github.com/nextcloud/docker/blob/35b8ebf954e7b55a1d1d61a8ea05bd7452abbd53/docker-entrypoint.sh#L209-L212

The clean-up appears to have been dropped in #1905, but that's not new: it's been like that for nearly two years.

So we have two questions we need to firm up answers for:

• Mystery: Why hasn't this been a problem until now for the integrity checker?
• Practical: Should we be cleaning up this lock file? (I believe yes).

Cc: @skjnldsv, @remram44

[remram44]

I believe this should be safe as long as you're holding the exclusive lock when you delete the file. edit: it's not

[marco-calautti]

Do you know any workaround, in the meanwhile, that we can use to make the error disappear?

[remram44]

Removing lock files is actually really tricky. One option would be to put it somewhere outside of the Nextcloud installation path, but it still needs to be inside the shared persistent volume.

To remove it, we would need to add an additional check to avoid the race condition where one process removes the file while another has opened it but not yet called flock. The entrypoint would also need to loop when that happens. (see this stackoverflow question)

Keeping the file around is much simpler, hopefully there's a way to do that without triggering integrity warnings?

[marco-calautti]

why can't the lock file be generated in the tmp directory, as it is standard in many scenarios in linux? The container should have /tmp available, right?

[remram44]

The lock file needs to be shared with all containers, since its purpose is to prevent different containers from running the upgrade at the same time.

[marco-calautti]

According to this: https://github.com/nextcloud/server/blob/bc5222726b7f6f04308231ff55b8e89ade582d37/lib/private/IntegrityCheck/Checker.php#L324

the updater folder is completely excluded from the integrity check. Could you save the lock there?

It actually would make a lot of sense, as you have a similar issue as the Nextcloud devs have (and that is why they exclude the updater directory from the check).

[kesselb]

It actually would make a lot of sense, as you have a similar issue as the Nextcloud devs have (and that is why they exclude the updater directory from the check).

https://github.com/nextcloud/server/blob/bc5222726b7f6f04308231ff55b8e89ade582d37/lib/private/IntegrityCheck/Iterator/ExcludeFileByNameFilterIterator.php

https://github.com/nextcloud/server/blob/bc5222726b7f6f04308231ff55b8e89ade582d37/lib/private/IntegrityCheck/Iterator/ExcludeFoldersByPathFilterIterator.php

I guess a pull request, to add nextcloud-init-sync.lock as an excluded file, would be acceptable.
Please don't hesitate to shoot a pr for server.

[prprprPro]

So any solution for now? Chmod and delete file neither works.

[kesselb]

@prprprPro the purpose of the integrity check is to let you, as administrator, know that the nextcloud installation is modified. A possible reason could be a patch that you applied or an external service that created a file that we do not expect. You need to check if that's a problem.

If you cannot delete the file, then you have to live with the warning. The integrity check is expensive and therefore the result cached, if you still see the warning after deleting the file: Trigger a rescan.

[SwallowYourDreams]

Do you know any workaround, in the meanwhile, that we can use to make the error disappear?

To get rid of the error, delete the file and trigger an integrity rescan from your admin panel (the link to it is part of the error message).

That said, there's really nothing truly wrong with your nextcloud instance; the message is a nuisance, a false positive, and nothing more (until it will be fixed. Also, expect the error to reappear once you restart or rebuild your container (e.g. after an update).