[Bug]: Integrity issue "nextcloud-init-sync.lock" after updating docker container #2057

WAdama · 2023-08-12T10:33:58Z

⚠️ This issue respects the following points: ⚠️

This is a bug, not a question or a configuration/webserver/proxy issue.
This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
I agree to follow Nextcloud's Code of Conduct.

Bug description

After updating docker container from 27.0.1 to 27.0.2 the integrity check failed:

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] => 
                        )

                )

        )

)

Log entry:

[PHP] Fehler: hash_file(/var/www/html/nextcloud-init-sync.lock): Failed to open stream: Permission denied at /var/www/html/lib/private/IntegrityCheck/Checker.php#211

GET /settings/integrity/rescan?requesttoken=<sanitized>
from 192.168.181.17 by <sanitized> at 2023-08-11T21:07:06+00:00

Steps to reproduce

Installed 27.0.1 passed this test
Updating docker container to 27.0.2
Test fails with mentioned message

Expected behavior

Integrity check should show no error

Installation method

Community Docker image

Nextcloud Server version

27

Operating system

Other

PHP engine version

PHP 8.2

Web server

Other

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Updated from a MINOR version (ex. 22.1 to 22.2)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

Default user-backend (database)
LDAP/ Active Directory
SSO - SAML
Other

Configuration report

{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "filelocking.enabled": true,
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "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": [
            "nextcloud.service.mydomain:50015"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "27.0.2.1",
        "overwrite.cli.url": "http:\/\/nextcloud.service.mydomain.de:50015",
        "overwriteprotocol": "https",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "ssl",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
        "skeletondirectory": "",
        "default_phone_region": "DE",
        "maintenance": false,
        "loglevel": 2
    }
}

List of activated Apps

Enabled:
  - activity: 2.19.0
  - bruteforcesettings: 2.7.0
  - calendar: 4.4.4
  - circles: 27.0.1
  - cloud_federation_api: 1.10.0
  - comments: 1.17.0
  - contacts: 5.3.2
  - contactsinteraction: 1.8.0
  - dashboard: 7.7.0
  - dav: 1.27.0
  - federatedfilesharing: 1.17.0
  - federation: 1.17.0
  - files: 1.22.0
  - files_pdfviewer: 2.8.0
  - files_rightclick: 1.6.0
  - files_sharing: 1.19.0
  - files_trashbin: 1.17.0
  - files_versions: 1.20.0
  - firstrunwizard: 2.16.0
  - groupfolders: 15.0.2
  - logreader: 2.12.0
  - lookup_server_connector: 1.15.0
  - nextcloud_announcements: 1.16.0
  - notifications: 2.15.0
  - oauth2: 1.15.1
  - password_policy: 1.17.0
  - photos: 2.3.0
  - privacy: 1.11.0
  - provisioning_api: 1.17.0
  - recommendations: 1.6.0
  - related_resources: 1.2.0
  - serverinfo: 1.17.0
  - settings: 1.9.0
  - sharebymail: 1.17.0
  - support: 1.10.0
  - survey_client: 1.15.0
  - systemtags: 1.17.0
  - tasks: 0.15.0
  - text: 3.8.0
  - theming: 2.2.0
  - twofactor_backupcodes: 1.16.0
  - twofactor_totp: 9.0.0
  - updatenotification: 1.17.0
  - user_ldap: 1.17.0
  - user_status: 1.7.0
  - viewer: 2.1.0
  - weather_status: 1.7.0
  - workflowengine: 2.9.0
Disabled:
  - admin_audit: 1.17.0
  - encryption: 2.15.0
  - files_external: 1.19.0
  - suspicious_login: 5.0.0

Nextcloud Signing status

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] => 
                        )

                )

        )

)

Nextcloud Logs

[PHP] Fehler: hash_file(/var/www/html/nextcloud-init-sync.lock): Failed to open stream: Permission denied at /var/www/html/lib/private/IntegrityCheck/Checker.php#211

GET /settings/integrity/rescan?requesttoken=<sanitized>
from 192.168.181.17 by <sanitized> at 2023-08-11T21:07:06+00:00

Additional info

Running on Synology DSM 7.2 / Docker 20.10.23

The text was updated successfully, but these errors were encountered:

joshtrichards · 2023-08-12T11:53:49Z

(/var/www/html/nextcloud-init-sync.lock): Failed to open stream: Permission denied

This seems a clue. Something appears to be up with the file permissions on your Docker mount for /var/www/html.

Check the file ownership and permissions of this file/folder and parents.

I suspect this is a local environment/configuration issue.

WAdama · 2023-08-12T12:54:04Z

Hi @joshtrichards

Thanks for your answer. I thought that, too.
The file has the following rights:
-rwx------+ 1 root root 0 Aug 11 23:27 nextcloud-init-sync.lock
All other files looks like this one:
-rw-r--r-- 1 33 33 3187 Aug 11 22:00 public.php

But the environment has not be changed from 27.0.1 to 27.0.2, the file had the same rights under 27.0.1. 27.0.1 has not shown this error.

If I delete it and restart the container, it will recreated with the same rights.

If I change the rights equivalent to the other ones, it makes also no difference.

joshtrichards · 2023-08-13T14:01:29Z

Please share your Docker Compose file.

WAdama · 2023-08-13T16:43:31Z

Hi Josh,

of course:

`version: "3"

services:
  cache:
    image: redis:latest
    container_name: Nextcloud_Cache
    healthcheck:
      test: [ "CMD", "redis-cli", "ping" ]
      interval: 30s
      timeout: 10s
      retries: 5
    volumes:
      - /volume1/docker/nextcloud/cache:/data
    networks:
      net:
    restart: unless-stopped

  nextcloud:
    image: nextcloud:latest
    container_name: Nextcloud
    hostname: nextcloud.service.asche-rz.de
    depends_on:
      - cache
    ports:
      - 3335:80
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80"]
      interval: 30s
      timeout: 10s
      retries: 5
    volumes:
      - /volume1/docker/nextcloud/main:/var/www/html
      - /volume1/DockerData/NextcloudHub/data:/data
    environment:
      REDIS_HOST: cache
    restart: unless-stopped
    networks:
      net:
      mariadb:
      
networks:
  net:
  mariadb:
    external: true`

I tried to keep it simple. But if there's mistake in my compose file, please fire away.

By the way, I checked it with a new installation and it shows the same error.

The strange thing is the file noted as extra file is created by the Nextcloud container.

Reagrds
Ingo

WAdama · 2023-08-18T06:31:17Z

By the way, after the last two image updates, the message still appears...

joshtrichards · 2023-08-18T13:58:47Z

Your file permissions indicate you're using ACLs:

https://wiki.archlinux.org/title/Access_Control_Lists#Output_of_ls_command
https://kb.synology.com/en-us/DSM/tutorial/permission_faq

I'd review what the real underlying permissions are on that file on your Synology.

The issue may also be related to libseccomp and either the version (generally old) in Synology's OS or the lack thereof.

You might be able to workaround it by adding this to the nextcloud container entry:

  security_opt:
    - seccomp=unconfined

But I can't promise that.

I'm actually kind of surprised that the /var/www/html/nextcloud-init-sync.lock file manages to get created at all.

See:

The strange thing is the file noted as extra file is created by the Nextcloud container.

The reason the integrity check is failing on it is because the check can't even open the file to do the check on it in your environment for some reason.

WAdama · 2023-08-18T15:27:14Z

Hi Josh,

I try that...

What's causing the creation of this file? Maybe the problem lies there and it is something in my installation, that i can have a look on.

Thanks and regards
Ingo

joshtrichards · 2023-08-18T17:20:54Z

The lock file gets created every time a container running this image starts up. It's used to make sure another process (or container with the same volume mounted) isn't already trying to install/upgrade the version of Nextcloud installed in /var/www/html in the container.

docker/docker-entrypoint.sh

Lines 135 to 136 in c496644

    
           # If another process is syncing the html folder, wait for 
        
           # it to be done, then escape initalization.

If I hadn't noticed the ACL permissions (that's what the + indicates), I would have assumed this was entirely a host OS libseccomp / Docker Engine version combination matter (which it could still be because it manifests a little differently depending on which system calls get blocked/etc.).

WAdama · 2023-08-18T18:04:12Z

The seccomp option changed nothing, I've just tried that.

I restored my Nextcloud container from before the update to 27.0.2 to a parallel installation.

With this 27.0.1 (27.0.1.2 according to config.php) the error disappears. The checks ends with "All checks passed." as expected. The ACL are the same. So a question would be, what has changed between this versions?

When this file is only needed in case of other processes tried access this volume, is there an option to stop this? The volume is used by nothing other than the Nextloud container.

WAdama · 2023-09-10T18:30:31Z

Sorry for answering so late, I wanted to be sure it works over new updates.

I tried again to set the rights of the file to www-data:www-data. This time it worked and the board is green again.

The only difference: I checked it first in ssh with "occ integrity:check-core". That showed no error and in GUI no error is shown, too.

It also survived two new docker images.

So I think there's nothing more to do in this case...

Thanks for your help!

pinkfloydFR · 2024-09-23T05:54:43Z

Sorry for answering so late, I wanted to be sure it works over new updates.

I tried again to set the rights of the file to www-data:www-data. This time it worked and the board is green again.

The only difference: I checked it first in ssh with "occ integrity:check-core". That showed no error and in GUI no error is shown, too.

It also survived two new docker images.

So I think there's nothing more to do in this case...

Thanks for your help!

not working for me :(

joshtrichards · 2024-09-23T12:27:45Z

@pinkfloydFR See #2299 if you're seeing this with v30.

WAdama added 0. Needs triage bug labels Aug 12, 2023

szaimen transferred this issue from nextcloud/server Aug 12, 2023

joshtrichards added needs info Additional info needed to triage and removed bug labels Aug 18, 2023

joshtrichards closed this as completed Sep 10, 2023

joshtrichards mentioned this issue Oct 3, 2023

[Bug]: nextcloud-init-sync.lock considered as extra file by the scanner #2070

Closed

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Bug]: Integrity issue "nextcloud-init-sync.lock" after updating docker container #2057

[Bug]: Integrity issue "nextcloud-init-sync.lock" after updating docker container #2057

WAdama commented Aug 12, 2023 •

edited by joshtrichards

Loading

joshtrichards commented Aug 12, 2023

WAdama commented Aug 12, 2023

joshtrichards commented Aug 13, 2023 •

edited

Loading

WAdama commented Aug 13, 2023 •

edited by joshtrichards

Loading

WAdama commented Aug 18, 2023

joshtrichards commented Aug 18, 2023 •

edited

Loading

WAdama commented Aug 18, 2023

joshtrichards commented Aug 18, 2023 •

edited

Loading

WAdama commented Aug 18, 2023 •

edited

Loading

WAdama commented Sep 10, 2023

pinkfloydFR commented Sep 23, 2024

joshtrichards commented Sep 23, 2024

[Bug]: Integrity issue "nextcloud-init-sync.lock" after updating docker container #2057

[Bug]: Integrity issue "nextcloud-init-sync.lock" after updating docker container #2057

Comments

WAdama commented Aug 12, 2023 • edited by joshtrichards Loading

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Installation method

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

Is this bug present after an update or on a fresh install?

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

joshtrichards commented Aug 12, 2023

WAdama commented Aug 12, 2023

joshtrichards commented Aug 13, 2023 • edited Loading

WAdama commented Aug 13, 2023 • edited by joshtrichards Loading

WAdama commented Aug 18, 2023

joshtrichards commented Aug 18, 2023 • edited Loading

WAdama commented Aug 18, 2023

joshtrichards commented Aug 18, 2023 • edited Loading

WAdama commented Aug 18, 2023 • edited Loading

WAdama commented Sep 10, 2023

pinkfloydFR commented Sep 23, 2024

joshtrichards commented Sep 23, 2024

WAdama commented Aug 12, 2023 •

edited by joshtrichards

Loading

joshtrichards commented Aug 13, 2023 •

edited

Loading

WAdama commented Aug 13, 2023 •

edited by joshtrichards

Loading

joshtrichards commented Aug 18, 2023 •

edited

Loading

joshtrichards commented Aug 18, 2023 •

edited

Loading

WAdama commented Aug 18, 2023 •

edited

Loading