[Bug]: 32.0.5.0 (client 3.17.4) etag changes on unchanged file

[Bockeman]

⚠️ 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

I create a file and observe that the file has been uploaded to the server.
Shortly after I observe that the etag changes on that uploaded file.

2026-03-15 20:20:17

  : > nextcloud_stress_000.txt

2026-03-15 20:21:26

  curl --insecure --netrc --silent --show-error --fail -X PROPFIND -H 'Depth: 1' ${webdav_url}
    <d:response>
      <d:href>/nextcloud/remote.php/dav/files/bobw/Experiment/nextcloud_stress_000.txt</d:href>
      <d:propstat>
        <d:prop>
          <d:getlastmodified>Sun, 15 Mar 2026 20:21:03 GMT</d:getlastmodified>
          <d:getcontentlength>0</d:getcontentlength>
          <d:resourcetype/>
          <d:getetag>"88c99086c6d98de020ab8e2f8a09c5b9"</d:getetag>
          <d:getcontenttype>text/plain</d:getcontenttype>
        </d:prop>
        <d:status>HTTP/1.1 200 OK</d:status>
      </d:propstat>
    </d:response>

2026-03-15 20:21:35

    <d:response>
      <d:href>/nextcloud/remote.php/dav/files/bobw/Experiment/nextcloud_stress_000.txt</d:href>
      <d:propstat>
        <d:prop>
          <d:getlastmodified>Sun, 15 Mar 2026 20:20:17 GMT</d:getlastmodified>
          <d:getcontentlength>0</d:getcontentlength>
          <d:resourcetype/>
          <d:getetag>"57ff9ebccea81e6e04bc62d659d22d97"</d:getetag>
          <d:getcontenttype>text/plain</d:getcontenttype>
        </d:prop>
        <d:status>HTTP/1.1 200 OK</d:status>
      </d:propstat>
    </d:response>

Notice the change in etag:

  88c99086c6d98de020ab8e2f8a09c5b9
  57ff9ebccea81e6e04bc62d659d22d97

Steps to reproduce

1. Set up a Nextcloud Server (which emulates a remote connection with ~100ms delay)
2. Set up a Nextcloud Client and Add Folder Sync Connection to folder "Experiment" (not virtual)
3. Start a script loop containing "curl ... ${webdav_url}"
4. Create a file ( : > nextcloud_stress_000.txt )
5. Observe the upload to the server (from the curl script loop)
6. Observe the etag change on the server (from the curl script loop)

Standalone nextcloud environment for demonstrating issues.

Server:

sudo -u apache php -f /usr/share/nextcloud/console.php config:list system | grep version\.:
  "version": "32.0.5.0",

Client:

nextcloud --version
  Nextcloud version 3.17.4daily
  Git revision 371e4b9311e851dbb8d6ae6f7c3f77af958e1a33
  Using Qt 6.10.1, built against Qt 6.10.1
  Using Qt platform plugin 'xcb'
  Using 'OpenSSL 3.5.4 30 Sep 2025'
  Running on Fedora Linux 43 (Forty Three), x86_64

Expected behavior

one unique etag per unique file

Nextcloud Server version

32

Operating system

Other

PHP engine version

PHP 8.4

Web server

Apache (supported)

Database engine version

MariaDB

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

Fresh Nextcloud Server install

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

sudo -u apache php -f /usr/share/nextcloud/console.php config:list system | grep version\.:
  "version": "32.0.5.0",

List of activated Apps

Not relevant

Nextcloud Signing status

None relevant.

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
=======
- suspicious_login
	- INVALID_HASH
		- vendor/amphp/parallel/.github/workflows/ci.yml
		- vendor/amphp/process/.github/workflows/ci.yml
	- FILE_MISSING
		- vendor/andrewdalpino/okbloomer/.github/FUNDING.yml
		- vendor/andrewdalpino/okbloomer/.github/workflows/ci.yml
- photos
	- INVALID_HASH
		- vendor/hexogen/kdtree/.github/workflows/tests.yml

Nextcloud Logs

I don't think the 30MB log file is helpful.
tail -5 /extra/server/nextcloud/nextcloud.log
  {"reqId":"abgGm6e2MeDYflpwum2YggAAAQU","level":1,"time":"March 16, 2026 13:33:16","remoteAddr":"192.168.0.15","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.5.0","clientReqId":"8ef47d68-3b37-428a-ae92-5aa8a7dc6a22","data":[]}
  {"reqId":"abgGpMPkE81TzJ56x83kFAAAAUA","level":1,"time":"March 16, 2026 13:33:25","remoteAddr":"192.168.0.13","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.5.0","clientReqId":"e55a9146-4276-4745-985a-246ae0809987","data":[]}
  {"reqId":"abgGr8PkE81TzJ56x83kFwAAAUg","level":1,"time":"March 16, 2026 13:33:35","remoteAddr":"127.0.0.1","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Linux) mirall/3.17.4daily (Nextcloud, fedora-6.18.12-200.fc43.x86_64 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.5.0","clientReqId":"0cd7a78e-9566-4f6a-9362-422ef2c105cd","data":[]}
  {"reqId":"abgGu8PkE81TzJ56x83kHAAAAU4","level":1,"time":"March 16, 2026 13:33:48","remoteAddr":"192.168.0.15","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.5.0","clientReqId":"b0064110-7e56-420c-a7f1-f780dbeab18c","data":[]}
  {"reqId":"abgGxMPkE81TzJ56x83kIQAAAUU","level":1,"time":"March 16, 2026 13:33:57","remoteAddr":"192.168.0.13","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.5.0","clientReqId":"9abf3c24-82e0-4c45-a2f9-9baf411b3cf4","data":[]}

Additional info

I suspect this behaviour is the cause real problems in my production environment.
It is reproducable, but may take thousands of attempts to capture.
That is possibly because of the relative timing of the file creation and the slow curl accesses.

[joshtrichards]

Good catch! There does look like there is brief window where the file is written out before the client-provided mtime is applied:

server/apps/dav/lib/Connector/Sabre/File.php

Line 346 in c826288

$mtimeHeader = $this->request->getHeader('x-oc-mtime');

This shouldn't matter for the client itself though: it's not going to see the etag until the request completes (which will have the correct mtime applied) -- but it could be confusing to other requestors during that narrow window. (It could also be a problem for concurrent requests from the same client I suppose...)

I suspect this behaviour is the cause real problems in my production environment.

I agree it's not ideal and should be remedied if possible, but can you elaborate on the situation you encountered that triggered this troubleshooting path?