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.

docker/docker-entrypoint.sh

Line 277 in 30b570f

) 9> /var/www/html/nextcloud-init-sync.lock

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:

docker/docker-entrypoint.sh

Lines 209 to 212 in 35b8ebf

	# Initialization done, reset lock
	rm $lock
	echo "Initializing finished"
	fi

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?