So I've got more investigation results. I no longer think it is the Last Access difference that is relevant, but rather differences in the SMB request pattern from the client that triggers buggy server behavior.
First, the updated results: 1. To reproduce, The file must be non-empty. The issue does not reproduce with an empty file. 2. This reproduces using Ubuntu Server 20.04.6 LTS and 22.04.3 LTS as the client, and two different Synology NAS machines, one running the latest DSM 7.1, the other running the latest DSM 7.2. A shared folder on a "Basic" single disk volume/storage pool is all that is needed. 3. This does not reproduce when the client is the latest archlinux 2024.01.01 ISO or Ubuntu Server 23.10, or with Windows 10 via command line "copy". 4. This does not reproduce when the *server* is changed to an Ubuntu 22.04.3 LTS box, even when it is running on BTRFS. This is surprising b/c Ubuntu 22.04.3 LTS and the Synology server both run Samba 4.15.13. 5. This does not reproduce when the server is TrueNAS (running 13.0-U3.1) So now we can look at a number of network traces and see what is different. One thing sticks out. The traces are definitely "cleaner" in the archlinux and ubuntu server 23.10 cases. In Ubuntu 20 and Ubuntu 22, the packet that sets the file info has that request "wrapped' by create file/close file SMB messages. In Ubuntu 23.10 and arch, these wrapper create/close are not present in the packet that sets the file info. While I don't think Ubuntu 20/22 are doing anything wrong, I could see the extra create file/close file messages causing the Synology server to lose track of the fact that the last operation on the file was to set the mod time, and that when the file is closed it's mod time does not need to be updated. Then when the final file close message comes in, the mod time is incorrectly updated (because the file had bytes written to it before the mod time was set). Finally, it is worth asking *why* the traces in arch/Ubuntu23 are cleaner/different. Both of those use cifs-utils 7.0, while Ubuntu 20/22 are on 6.x . But I don't see anything in the 7.0 commits that relates to this. I may just be looking in the wrong place. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2007055 Title: cifs/samba mount not preserving file timestamps Status in linux package in Ubuntu: Fix Released Status in linux source package in Jammy: Incomplete Bug description: I think I've found a bug or regression in something when trying to mount a remote samba share. Modified/Created times are not properly preserved in newer versions of Ubuntu. Because of this, rsync thinks files are different based on their modified times and keeps re-syncing them. I have a NAS on my network, running samba. I have two devices, a desktop and laptop. Both are running Ubuntu, and set up the exact same way. The desktop is running ubuntu 20.04, the laptop 22.04. I have mounted the NAS on both devices the exact same way. I attempt to copy a file (rsync) the exact same way. On the 20.04 desktop, this works perfectly fine. On the 22.04 laptop, the modified times are not preserved and set to the current time, preventing things like rsync -t from working. The only difference i can find is that between the two systems, the newer laptop 22.04 mount adds a few more options than the older system to the cifs mount options. These are added automatically without being specified explicitly (see the mount -v output below): * 'forceuid'/'forcegid' are changed to 'noforceuid'/'noforcegid * iocharset=utf8 added * serverino added desktop: $ lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 $ apt-cache policy cifs-utils cifs-utils: Installed: 2:6.9-1ubuntu0.2 Candidate: 2:6.9-1ubuntu0.2 Version table: *** 2:6.9-1ubuntu0.2 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2:6.9-1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages $ uname -a Linux desktop 5.4.0-132-generic #148-Ubuntu SMP Mon Oct 17 16:02:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux $ mount -v //nas/backup on /media/scratch type cifs (rw,relatime,vers=3.0,cache=strict,username=nas_rw,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.1.10,file_mode=0664,dir_mode=0775,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1) laptop: $ lsb_release -rd Description: KDE neon 5.26 Release: 22.04 $ apt-cache policy cifs-utils cifs-utils: Installed: 2:6.14-1ubuntu0.1 Candidate: 2:6.14-1ubuntu0.1 Version table: *** 2:6.14-1ubuntu0.1 500 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 100 /var/lib/dpkg/status 2:6.14-1build1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages $ uname -a Linux laptop 5.15.0-60-generic #66-Ubuntu SMP Fri Jan 20 14:29:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux $ mount -v //nas/backup on /media/scratch type cifs (rw,relatime,vers=3.0,cache=strict,username=nas_rw,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.1.10,file_mode=0664,dir_mode=0775,iocharset=utf8,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1) the remote NAS is a synology appliance, running Samba version 4.10.18. SMB version 3 Steps to reproduce: 1. Similar setup, 1 device running 20.04, another running 22.04, otherwise up to date. 2. mount the NAS on both devices the exact same way $ sudo mount -t cifs -o vers=3.0,credentials=/etc/samba/smbcreds,iocharset=utf8,rw,uid=1000,gid=1000,dir_mode=0775,file_mode=0664 //nas/backup /media/scratch 3. on the 20.04 older desktop, create a test file and show the modify time $ fallocate -l 1M test1.txt $ stat test1.txt File: test1.txt Size: 1048576 Blocks: 2048 IO Block: 4096 regular file Device: 801h/2049d Inode: 13634663 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/desktop_user) Gid: ( 1000/desktop_user) Access: 2023-02-12 18:35:48.978743377 -0700 Modify: 2023-02-12 18:35:48.978743377 -0700 Change: 2023-02-12 18:35:48.978743377 -0700 Birth: - 4. rsync the test file to the mount, stat the file and see the modify/change are preserved $ rsync -avh test1.txt /media/scratch/ sending incremental file list test1.txt sent 1.05M bytes received 35 bytes 2.10M bytes/sec total size is 1.05M speedup is 1.00 $ stat /media/scratch/test1.txt File: /media/scratch/test1.txt Size: 1048576 Blocks: 2064 IO Block: 1048576 regular file Device: 52h/82d Inode: 321811 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/desktop_user) Gid: ( 1000/desktop_user) Access: 2023-02-12 18:38:25.671230900 -0700 Modify: 2023-02-12 18:35:48.978743300 -0700 Change: 2023-02-12 18:35:48.978743300 -0700 Birth: - 5. rsync again, notice the file is correctly skipped. $ rsync -avh test1.txt /media/scratch/ sending incremental file list sent 68 bytes received 12 bytes 160.00 bytes/sec total size is 1.05M speedup is 13,107.20 6. repeat the same steps above on the newer 22.04 laptop, only this time notice that the modify/change are NOT preserved. rsync re-sends the file because modified time changed. $ fallocate -l 1M test2.txt $ stat test2.txt File: test2.txt Size: 1048576 Blocks: 2048 IO Block: 4096 regular file Device: fd00h/64768d Inode: 526622 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ laptop_user) Gid: ( 1000/ laptop_user) Access: 2023-02-12 18:42:55.467521856 -0700 Modify: 2023-02-12 18:42:55.467521856 -0700 Change: 2023-02-12 18:42:55.467521856 -0700 Birth: 2023-02-12 18:42:55.467521856 -0700 $ rsync -avh test2.txt /media/scratch/ sending incremental file list test2.txt sent 1.05M bytes received 35 bytes 2.10M bytes/sec total size is 1.05M speedup is 1.00 $ stat /media/scratch/test2.txt File: /media/scratch/test2.txt Size: 1048576 Blocks: 2064 IO Block: 1048576 regular file Device: 54h/84d Inode: 565291 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ laptop_user) Gid: ( 1000/ laptop_user) Access: 2023-02-12 18:43:24.265024500 -0700 Modify: 2023-02-12 18:43:24.265024500 -0700 Change: 2023-02-12 18:43:24.265024500 -0700 Birth: 2023-02-12 18:43:24.248938600 -0700 $ rsync -avh test2.txt /media/scratch/ sending incremental file list test2.txt sent 1.05M bytes received 35 bytes 2.10M bytes/sec total size is 1.05M speedup is 1.00 $ stat /media/scratch/test2.txt File: /media/scratch/test2.txt Size: 1048576 Blocks: 2064 IO Block: 1048576 regular file Device: 54h/84d Inode: 565292 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ laptop_user) Gid: ( 1000/ laptop_user) Access: 2023-02-12 18:43:45.413195300 -0700 Modify: 2023-02-12 18:43:45.413195300 -0700 Change: 2023-02-12 18:43:45.413195300 -0700 Birth: 2023-02-12 18:43:45.398091900 -0700 As best I can tell I am doing _everything_ EXACTLY the same way. Word for word. The remote system is the same device, same share, same directory. The only difference is the software version, and the extra options thrown in automatically when mounting a cifs share. I've tried to 'unspecify' those extra bits but it still happens. I'd tag this to a proper package, but i'm not sure if this is cifs- tools, or something else entirely. The only thing I can find online that's possibly similar is this ask ubuntu thread: https://askubuntu.com/questions/1426772/after-upgrade-from-ubuntu-20-to-ubuntu-22-rsync-copies-unchanged-files-and-chan It sure looks like the same thing, but no solutions are presented. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2007055/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
