cifs/samba mount not preserving file timestamps

[Andy]

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.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Libera.chat.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/2007055/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Andy (andyman1)]

I found a few more pieces of information.

First, the different default parameters i found (forceuid/gid, iocharset, serverino) don't seem to make a difference. I figured out how to make them identical between the two systems and the problem was the same.

Second, what DID make a difference was changing the samba/cifs version protocol for the mount command. e.g. -o vers=x.y

For the 20.04 desktop, using vers=2.0, 2.1, 3.0, 3.11 all worked fine. modified times preserved and rsync behaves.

For the 22.04 laptop, using vers=2.1, 3.0, 3.11 all fail like above. BUT using vers=2.0 works correctly. modified times are preserved.

I also found that if I use KDE's Dolphin to copy a file, the modified times are preserved as well. I suspect it's also using SMB 2.0, which is why it succeeded. But a bit of additional info that it's not just an rsync problem.

[Andy (andyman1)]

As this was tagged 'samba'.

20.04 desktop:

$ apt-cache policy samba
samba:
  Installed: 2:4.13.17~dfsg-0ubuntu1.20.04.1
  Candidate: 2:4.13.17~dfsg-0ubuntu1.20.04.1
  Version table:
 *** 2:4.13.17~dfsg-0ubuntu1.20.04.1 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:4.11.6+dfsg-0ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages

22.04 laptop:

$ apt-cache policy samba
samba:
  Installed: 2:4.15.13+dfsg-0ubuntu1
  Candidate: 2:4.15.13+dfsg-0ubuntu1
  Version table:
 *** 2:4.15.13+dfsg-0ubuntu1 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:4.15.5~dfsg-0ubuntu5 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

[Otto Struve (okotto)]

I'm experiencing the exact same problem on Ubuntu Server 22.04. After upgrading from 20.04 to 22.04 daily backup to a cifs filesystem with rsync took much longer/did not complete at all. After some tests with random files, I figured that modify times are not preserved at first. But after multiple attempts to sync a folder the modify times are set correctly.

[Paride Legovini (paride)]

Hello and thanks for this bug report. I have to ask an obvious question: did you verify that problem only happens with samba shared, and that it is not an rsync bug? How does rsync behave is you take samba out of the equation? I'm asking as this report reminds me of this rsync bug:

  https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1965076

[Paride Legovini (paride)]

Also: what happens if you e.g. `touch` or `touch -m` a file on the samba share?

[Andy (andyman1)]

so I'll summarize first and then give some examples below.

In short, I'm pretty sure the issue is not rsync itself?

1. I tried rsyncing locally to /tmp instead of to the share, that works fine.
2. I used stat and ls to confirm that the modified file times were actually incorrect. Not just rsync messing up its interpretation.
3. I may have not explained this well earlier. from the 22.04 problem laptop if I change the mount option from "-o vers=3.0" to "-o vers=2.0" (i.e. change SMB protocol from v3 to v2), then rsync DOES succeed and behaves on resync. But only with exactly "2.0", not 2.1 or anything else. On the behaving 20.04 desktop, changing versions does not matter, it works regardless with any valid version.
4. looks like the linked bug is fixed with 3.2.3-8ubuntu3.1, and that's exactly what I have on the laptop. The desktop is a few version older.

I tried touch with -m and -d (I think that's what you meant? specify an alternate timestamp?) and that _does_ work when sent to the share.

Another interesting data point is that "cp -p" does _not_ work for _either_ client.

Between touch and cp's behavior that's...confusing?

some output examples:

rsync versions
---
20.04 good desktop:

$ apt list rsync
Listing... Done
rsync/focal-updates,focal-security,now 3.1.3-8ubuntu0.4 amd64 [installed]
rsync/focal-updates,focal-security 3.1.3-8ubuntu0.4 i386

22.04 bad laptop:

$ apt list rsync
Listing... Done
rsync/jammy-updates,now 3.2.3-8ubuntu3.1 amd64 [installed,automatic]
rsync/jammy-updates 3.2.3-8ubuntu3.1 i386

local rsync to /tmp attempt on 22.04 laptop:
----

$ rsync -avh test2.txt /tmp/
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
$ rsync -avh test2.txt /tmp/
sending incremental file list

sent 65 bytes received 12 bytes 154.00 bytes/sec
total size is 1.05M speedup is 13,617.87
$ stat /tmp/test2.txt
  File: /tmp/test2.txt
  Size: 1048576 Blocks: 2048 IO Block: 4096 regular file
Device: 28h/40d Inode: 3519 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ laptop_user) Gid: ( 1000/ laptop_user)
Access: 2023-02-23 16:55:53.792631806 -0700
Modify: 2023-02-12 18:42:55.467521856 -0700
Change: 2023-02-23 16:55:53.796631723 -0700
 Birth: -

using touch. Both cases with "-o vers=3.0" in mount options. I first touch a brand new file with an old date, then touch -m again to the existing file.
---

20.04 desktop

$ touch -d "2001-01-01" /media/scratch/test1.txt
$ stat /media/scratch/test1.txt
  File: /media/scratch/test1.txt
  Size: 0 Blocks: 16 IO Block: 1048576 regular empty file
Device: 52h/82d Inode: 2854778 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/desktop_user) Gid: ( 1000/desktop_user)
Access: 2001-01-01 00:00:00.000000000 -0700
Modify: 2001-01-01 00:00:00.000000000 -0700
Change: 2001-01-01 00:00:00.000000000 -0700
 Birth: -
$ touch -m /media/scratch/test1.txt
$ stat /media/scratch/test1.txt
  File: /media/scratch/test1.txt
  Size: 0 Blocks: 16 IO Block: 1048576 regular empty file
Device: 52h/82d Inode: 2854778 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/desk...

[Launchpad Janitor (janitor)]

[Expired for samba (Ubuntu) because there has been no activity for 60 days.]

[Athos Ribeiro (athos-ribeiro)]

Hi Andy, Otto.

This was set to expired due to the time it remained inactive in the incomplete state.

I am setting this bug back to incomplete so we can keep gathering information on the issue.

Would any of you be able to come up with a minimal reproducer we could easily set up with virtual machines?

Then we could isolate the issue and start figuring out if this is indeed a bug with samba (or rsync) and come up with a potential fix.

[Andy (andyman1)]

Hello,

Apologies for the delay, following up now.

At some point, some sort of update appears to have fixed the issue. I can confirm that my samba mount is preserving timestamps now and rsync now behaves with incremental updates. Everything's fine now.

The output of my currently installed versions of samba, cifs-utils, and rsync is below. In short I see two differences. old -> new versions on the laptop.

rsync 3.2.3-8ubuntu3.1 -> 3.2.7-0ubuntu0.22.04.2
samba 2:4.15.13+dfsg-0ubuntu1 -> 2:4.15.13+dfsg-0ubuntu1.1
cifs-utils identical.

So I'm guessing one of those two updates fixed things? And hopefully for good?

Let me know if I can provide any further info. And good luck to Otto, hope yours is fixed as well.

Thanks,
Andy

$ apt list samba
Listing... Done
samba/jammy-security,jammy-updates,now 2:4.15.13+dfsg-0ubuntu1.1 amd64 [installed]
N: There is 1 additional version. Please use the '-a' switch to see it

$ apt list cifs-utils
Listing... Done
cifs-utils/jammy-security,jammy-updates,now 2:6.14-1ubuntu0.1 amd64 [installed]
cifs-utils/jammy-security,jammy-updates 2:6.14-1ubuntu0.1 i386

$ apt list rsync
Listing... Done
rsync/jammy-security,jammy-updates,now 3.2.7-0ubuntu0.22.04.2 amd64 [installed,automatic]
rsync/jammy-security,jammy-updates 3.2.7-0ubuntu0.22.04.2 i386

[Paride Legovini (paride)]

Thanks Andy for letting us know and glad to hear the problem has been fixed at some point. I'll mark this bug report Fix Released.

[Otto Struve (okotto)]

Thanks Andy for commenting!

Mine is fixed as well with the new version.

[Mint Platz (mintplaetzchen)]

Sorry to spoil the fun, but it seems updating did not fix it - at least not for me.

I'm facing the pretty weird issue that the exact same rsync script I have been using for years does not preserve the creation time on a NAS mounted via SMB share with the latest version of Linux Mint Mate (21.2). I even tried

cp -a ~/TheFile.txt /media/NAS/share/.

and TheFile.txt received the CURRENT time/date on the NAS.

HOWEVER: Using the Caja file browser or Double Commander retained the CORRECT time stamp! When I was watching the copy process taking place for a large file, the file was first created with the current date/time and the original file's date/time then (re?)applied after the copy process has completed.

These are my rsync parameters:

--verbose --archive --open-noatime --atimes --update --human-readable --safe-links --stats --executability --acls --xattrs

, but even the most basic setup --archive --update did not do the trick.

The NAS was mounted with

/NAS/share /media/NAS/share cifs noauto,users,credentials=/home/user/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0

in /etc/fstab (NAS access credentials are in /user/.smbcredentials). There's also nothing fancy in my /etc/samba/smb.conf - with the potential exception of

[global]
   workgroup = MUNICH
   NetBIOS name = HOMEPC
   name resolve order = bcast lmhosts host wins
   client min protocol = NT1
   server min protocol = NT1

which IMHO shouldn't affect these things. These are the versions of the toolset:

rsync -V
rsync version 3.2.7 protocol version 31
Copyright (C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others.
Web site: https://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, symlinks, symtimes, hardlinks, hardlink-specials,
    hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs,
    xattrs, optional secluded-args, iconv, prealloc, stop-at, no crtimes
Optimizations:
    SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
Checksum list:
    xxh128 xxh3 xxh64 (xxhash) md5 md4 sha1 none
Compress list:
    zstd lz4 zlibx zlib none
Daemon auth list:
    sha512 sha256 sha1 md5 md4

apt list rsync
rsync/jammy-updates,jammy-security,now 3.2.7-0ubuntu0.22.04.2 amd64 [installed]
rsync/jammy-updates,jammy-security 3.2.7-0ubuntu0.22.04.2 i386

Samba:
Version 4.15.13-Ubuntu

apt list samba -a
samba/jammy-updates,now 2:4.15.13+dfsg-0ubuntu1.3 amd64 [installed]
samba/jammy-security 2:4.15.13+dfsg-0ubuntu1.2 amd64
samba/jammy 2:4.15.5~dfsg-0ubuntu5 amd64

apt list cifs-utils
cifs-utils/jammy-updates,jammy-security,now 2:6.14-1ubuntu0.1 amd64 [installed]
cifs-utils/jammy-updates,jammy-security 2:6.14-1ubuntu0.1 i386

Perhaps someone has a clue. Many thanks in advance for any help.

[Mitchell Dzurick (mitchdz)]

Thanks for taking the time to thoroughly describe your issue Mint!

It's interesting that things seem to work well with 2 tools (Caja, Double Explorer) but not cp/rsync. I'm not sure what to make of that yet.

Would you be able to create steps to reproduce this issue with VM(s)? That would help narrow down this issue and drive a resolution faster.

Setting bug to incomplete.

[Mint Platz (mintplaetzchen)]

Hi Mitchell!

Thanks for getting back to this issue so quickly. Highly appreciated. Meanwhile, I was digging into it a little more and things get even weirder. I created this script to compare the behaviour of Caja vs. cp --preserve vs. rsync --archive:

#!/bin/bash

source=~/Temp/MyFile.bin
target=/media/rn214/user/Temp/MyFile.bin

echo "Source: \"$source\""
rm -f "$source"
touch "$source"
ls -la "$source"
stat "$source"

echo
echo "Sleeping 10s..."
sleep 10

echo
echo "Target (cp): \"$target\""
cp --preserve "$source" "$target"
ls -la "$target"
stat "$target"

rm -f "$target"

echo
echo "Target (rsync): \"$target\""
rsync --archive "$source" "$target"
ls -la "$target"
stat "$target"

This gave me:

user@PCuser:~/Temp$ ./test.sh
Source: "/home/user/Temp/MyFile.bin"
-rw-rw-r-- 1 user user 0 Aug 28 19:02 /home/user/Temp/MyFile.bin
  File: /home/user/Temp/MyFile.bin
  Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 811h/2065d Inode: 19398755 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2023-08-28 19:02:22.496872521 +0200
Modify: 2023-08-28 19:02:22.496872521 +0200
Change: 2023-08-28 19:02:22.496872521 +0200
 Birth: 2023-08-28 19:02:22.496872521 +0200

Sleeping 10s...

Target (cp): "/media/rn214/user/Temp/MyFile.bin"
-rwxrwx--- 1 user user 0 Aug 28 19:02 /media/rn214/user/Temp/MyFile.bin
  File: /media/rn214/user/Temp/MyFile.bin
  Size: 0 Blocks: 0 IO Block: 1048576 regular empty file
Device: 42h/66d Inode: 116707 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2023-08-28 19:02:22.496872500 +0200
Modify: 2023-08-28 19:02:22.496872500 +0200
Change: 2023-08-28 19:02:32.576703700 +0200
 Birth: 2023-08-28 19:02:32.498947000 +0200

Target (rsync): "/media/rn214/user/Temp/MyFile.bin"
-rwxrwx--- 1 user user 0 Aug 28 19:02 /media/rn214/user/Temp/MyFile.bin
  File: /media/rn214/user/Temp/MyFile.bin
  Size: 0 Blocks: 0 IO Block: 1048576 regular empty file
Device: 42h/66d Inode: 116708 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2023-08-28 19:02:32.588948900 +0200
Modify: 2023-08-28 19:02:22.496872500 +0200
Change: 2023-08-28 19:02:22.496872500 +0200
 Birth: 2023-08-28 19:02:32.588948900 +0200

Then, I deleted the target file on the SMB share mounted with cifs and used Caja in two-pane-mode to copy the file over:

user@PCuser:~/Temp$ ls -la /media/rn214/user/Temp/MyFile.bin
-rwxrwx--- 1 user user 0 Aug 28 19:02 /media/rn214/user/Temp/MyFile.bin
user@PCuser:~/Temp$ stat /media/rn214/user/Temp/MyFile.bin
  File: /media/rn214/user/Temp/MyFile.bin
  Size: 0 Blocks: 0 IO Block: 1048576 regular empty file
Device: 42h/66d Inode: 116709 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2023-08-28 19:02:32.512704000 +0200
Modify: 2023-08-28 19:02:22.496872000 +0200
Change: 2023-08-28 19:02:22.496872000 +0200
 Birth: 2023-08-28 19:04:26.731171000 +0200

Looking fine so far. I then grabbed an old movie that I still had locally and repeated the process with Caja.

Source:
  File: /home/user/Movies/Der Pakt...

[Mitchell Dzurick (mitchdz)]

Mint, Thanks for doing more testing on your end!

I'm suspicious at this point if it's an issue with Samba. We see this issue with both rsync/cp which is strange, but the similar component in all of these tests are samba. Try changing your $target in the script to something on local disk and see if you encounter the same problem. If not, then I'd like to start digging into Samba and see if anything like this is noticed.

[Mitchell Dzurick (mitchdz)]

I know this bug is already in Samba, I just want to confirm the basics that it works properly on local disk and not when doing SMB share transfers :)

In the meantime, reproducing this with LXC containers/VMs would be a lot better as we can narrow down potential things causing this issue and share similar testing environments.

[Mint Platz (mintplaetzchen)]

Hi Mitchell!

Thanks again for your patience and persistence. I try to reward this with more findings... ;-)

Let's focus on what stat shows as "Modify" and "Change", where "Change" might be what the typical file browser (Caja, DoubleCmd) interprets as "Date". I start off with my (slightly modified) script:

source=~/Temp/test.bin
target=/media/rn214/user/Temp/test.bin

if [ ! -e "$source" ]; then
    echo "Creating: \"$source\"..."
    touch "$source"
    sleep 10
fi

echo "Source:"
stat "$source"

echo
echo "Target (cp --preserve \"$source\" \"$target\"):"
rm -f "$target"
cp --preserve "$source" "$target"
stat "$target"

echo
echo "Target (rsync --archive \"$source\" \"$target\"):"
rm -f "$target"
rsync --archive "$source" "$target"
stat "$target"

That results in:

Source:
  File: /home/user/Temp/test.bin
Modify: 2023-08-29 10:52:46.090944857 +0200
Change: 2023-08-29 10:52:46.090944857 +0200

Target (cp --preserve "/home/user/Temp/test.bin" "/media/rn214/user/Temp/test.bin"):
  File: /media/rn214/user/Temp/test.bin
Modify: 2023-08-29 10:52:46.090944800 +0200
Change: 2023-08-29 13:10:18.809337400 +0200

Target (rsync --archive "/home/user/Temp/test.bin" "/media/rn214/user/Temp/test.bin"):
  File: /media/rn214/user/Temp/test.bin
Modify: 2023-08-29 10:52:46.090944800 +0200
Change: 2023-08-29 10:52:46.090944800 +0200

(cutting away the irrelevant output for clarity's sake).

That indicates a different behaviour of cp --preserve vs rsync --archive: The former does not adjust the change date. I could live with that in a pinch.

Now a manual copy frm source to target with Caja:

 File: /media/rn214/user/Temp/test.bin
Modify: 2023-08-29 10:52:46.090944000 +0200
Change: 2023-08-29 10:52:46.090944000 +0200

- seems to rather mimic rsync's way of doing things. Now for the interesting part. I got this file:

  File: Der Pakt mit dem Teufel [1950.GER.H264.AAC.576p].mkv
  Size: 1127457487 Blocks: 2202080 IO Block: 4096 regular file
Device: 811h/2065d Inode: 21897600 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2023-08-28 19:55:25.183641164 +0200
Modify: 2016-03-24 10:43:36.804000000 +0100
Change: 2023-08-27 18:55:46.493351658 +0200
 Birth: 2023-08-23 23:45:53.104421855 +0200

Copying manually with Caja onto the NAS:

  File: /media/rn214/user/Temp/Der Pakt mit dem Teufel [1950.GER.H264.AAC.576p].mkv
  Size: 1127457487 Blocks: 2202112 IO Block: 1048576 regular file
Device: 35h/53d Inode: 116823 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2023-08-28 19:55:25.183641000 +0200
Modify: 2016-03-24 10:43:36.804000000 +0100
Change: 2016-03-24 10:43:36.804000000 +0100
 Birth: 2023-08-29 13:16:00.089281300 +0200

Deleted the target and repeat:

  File: /media/rn214/user/Temp/Der Pakt mit dem Teufel [1950.GER.H264.AAC.576p].mkv
  Size: 1127457487 Blocks: 2202112 IO Block: 1048576 regular file
Device: 35h/53d Inode: 116824 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2023-08-29 13:17:22.142932100 +0200
Modify: 2023-08-29 13:17:22.142932100 +0200
Change: 2023-08-29 13:17:22.142932100 +0200
 Birth: 2023-08-29 13:17:09.8201...

[Mint Platz (mintplaetzchen)]

Correction: Instead of...

<<Let's focus on what stat shows as "Modify" and "Change", where "Change" might be what the typical file browser (Caja, DoubleCmd) interprets as "Date". I start off with my (slightly modified) script>>

...I wanted to say:

<<Let's focus on what stat shows as "Modify" and "Change", where "MODIFY" might be what the typical file browser (Caja, DoubleCmd) interprets as "Date". I start off with my (slightly modified) script>>

But I think, that was evident from the rest of the investigation anyway.

[Mitchell Dzurick (mitchdz)]

Hi Mint, sorry for the delay in response, I haven't had a chance to look much more deeply into this. I'm adding server-todo so either me or someone else can assist soon.

I'd like to re-iterate that reproducing this behavior in VMs/LXC containers would help with narrowing down what's going on if that's a task you're willing to try out. This will allow us to debug in the same environment.

[Mint Platz (mintplaetzchen)]

Hi Mitchell!

I have VirtualBox here, so if it's reasonably easy to test the platform you're interested in, just tell me where to download the image. Of course, there's always the risk with the host trying to translate something for the guest which then breaks (or masks) things, but I can at least try.

[Mint Platz (mintplaetzchen)]

OK, good news here. I gave it a whirl with this kernel:

Linux PC 6.2.0-32-generic #32~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 18 10:40:13 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

and this one does not seem to have the problem. Tried to copy the objectionable file several times with doublecmd, rsync, cp and Caja and everytime the modification time was preserved.

My conclusion is that after the 4.x kernel (which tested OK) some regression was introduced showing up in 5.15.0-82 but not in 6.2.0-32 which is what I'm currently using. The file seems to particular in the sense that the "Change" timestamp is inconsistent with the "Modify" timestamp:

stat Der\ Pakt\ mit\ dem\ Teufel\ \[1950.GER.H264.AAC.576p\].mkv
  File: Der Pakt mit dem Teufel [1950.GER.H264.AAC.576p].mkv
  Size: 1127457487 Blocks: 2202080 IO Block: 4096 regular file
Device: 811h/2065d Inode: 21897600 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2023-09-06 09:54:20.607076576 +0200
Modify: 2016-03-24 10:43:36.804000000 +0100
Change: 2023-08-27 18:55:46.493351658 +0200
 Birth: 2023-08-23 23:45:53.104421855 +0200

and somehow cifs/SMB ended up overwriting the "Modify" attribute with the "Change" attribute.

I'm by no means an expert in that matter, but at least that seems plausible. Got to test my rsync backup scripts with the --update uption and a --dry-run, but things are looking good. Anyone experiencing the same problem should consider running a kernel update.

HOWEVER: According to the information I have, SMB 1.x was dropped in that release. So if you are having an antique NAS running in a mixed Linux/Windows environment with no possibility of applying a firmware update to bring SMB up to modern standards (or still have Windows 95/XP/7 clients without software updates), then there's trouble ahead.

In Linux-only networks, it's probably best to ditch SMB/SAMBA altogether and move on to the more lightweight NFS.

[Andreas Hasenack (ahasenack)]

Thanks for your last update.

cifs is indeed provided by the kernel, and mounted via mount.cifs from cifs-utils. Although similar in nature, this is not samba code. All of this discussion is pointing at something in the kernel, so I'm switching the bug task from samba to linux (which is the kernel).

[Mint Platz (mintplaetzchen)]

Hi Andreas!

Thanks for taking care. Of course I can not say 100% that the behaviour will never ever happen again with 6.2.0-32, because it was something like 4/10 on 5.15.0-82 with no clear pattern but I'll update this ticket if I have any news.

Perhaps you/someone can backport the fix from 6.2.0-32 to 5.15.0-83 because the latter seems to be LTS (until APR 2027) and the former rather short lived.

[Nicholas Neumann (aggienick02)]

So I encountered this recently as well. I've got some strong evidence that at least part of the problem is the SMB *server*, specifically a Synology NAS.

We are migrating from a TrueNAS to Synology, and I noticed the timestamp issue after rsync'ing files from an Ubuntu 22.04 client. I simplified by switching to cp -p and then proceeded to grab network captures of copying a single file from the client via cp -p.

Performing cp -p to the TrueNAS device preserves modification time. The same command to the synology device does not. The network captures are very similar. Of particular note, they both send the same SMB2_FILE_BASIC_INFO:
SMB2_FILE_BASIC_INFO
Create: No time specified (0)
Last Access: Jan 22, 2024 13:15:35.923752400 Central Standard Time
Last Write: Nov 22, 2023 13:15:09.416423500 Central Standard Time
Last Change: Jan 22, 2024 13:23:52.482749400 Central Standard Time
File Attributes: 0x00000000
Unknown: 00000000

Interestingly, on Windows, where a simple "copy" command line operation preserves the file modification time on the Synology share, sends slightly different info:
SMB2_FILE_BASIC_INFO
Create: No time specified (0)
Last Access: No time specified (0)
Last Write: Nov 22, 2023 13:15:09.416423500 Central Standard Time
Last Change: Jan 22, 2024 13:34:57.144137700 Central Standard Time
File Attributes: 0x00000000
Unknown: 00000000

[Mint Platz (mintplaetzchen)]

@Nicholas Neumann: Interesting! So the only difference is, that Windows clients do not specify the "Last Access" attribute. So in case of a Windows client, you expect and see a modification date of Nov 22, 2023 13:15:09 on the NAS, for the Linux client (which transmits the "Last Access" attribute), you expect Nov 22, 2023 13:15:09 but get Jan 22, 2024 13:15:35?

I'm a bit helpless in understanding how one would _change_ a file on Jan 22, 2024 13:23:52 without actually _writing_ to it (which happened on Nov 22, 2023 13:15:09) and why the time stamps for "Last Access" and "Last Change" are not identical, but that's probably just one more particularity of the Linux file system.

Whatever may be the case, I do not think it is correct when the Synology NAS' SMB server module confuses the presence of "Last Access" (which could have been either read or write) with "Last Change", effectively overwriting the modification date of the file (which seems to be defined by "Last Write").

SMB: the final frontier. These are the voyages of numerous Linux enthusiasts. Their perpetual mission: to explore strange new worlds; to seek out new software and new functionality; to boldly go where no man has gone before!

[Nicholas Neumann (aggienick02)]

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.

[Nicholas Neumann (aggienick02)]

Here is a comparison of the network captures between an Ubuntu Server 23.10 client and Ubuntu Server 22.04.3 LTS client. The difference noted is consistent with when the bug reproduces - that is, Windows 10, Ubuntu Server 23.10, and latest arch all have the SetInfo by itself and the bug does not reproduce. Ubuntu Server 22.04.3LTS and Ubuntu Server 20.04.6LTS have the SetInfo wrapped, and the bug does reproduce, but only with Synology as the Server.

With TrueNAS 13.0-U3.1 or Ubuntu 22.04.3 Server LTS as the server, the bug does not reproduce for any client, even though the SetInfo remains wrapped for some clients.

[Mint Platz (mintplaetzchen)]

> I no longer think it is the Last Access difference that is relevant,
> but rather differences in the SMB request pattern
> 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.

Dude, that's wild stuff. In essence that means that some component is not behaving standard compliant and the fix might not just be updating the client (to send "cleaner" messages) but the server as well. Which - in my case - is running on a NetGear RN214. No idea what the underlying OS is and if anyone over there at NetGear bothers to dig into things if I point them to this thread.

Final question is how I can find out for sure if my system is still affected.
uname -r tells me:
6.5.0-14-generic
and hostnamectl:
       Icon name: computer-desktop
         Chassis: desktop
Operating System: Linux Mint 21.2
          Kernel: Linux 6.5.0-14-generic
    Architecture: x86-64
, samba -V:
Version 4.15.13-Ubuntu

Do you have any recommendation for a script that I could run to find out? Something along the lines of...

#!/bin/bash

source=~/Temp/MyFile.bin
target=/media/rn214/user/Temp/MyFile.bin

echo "Source: \"$source\""
rm -f "$source"
touch "$source"
head -c 1k </dev/urandom >"$source"
ls -la "$source"
stat "$source"

echo
echo "Sleeping 10s..."
sleep 10

echo
echo "Target (cp): \"$target\""
cp --preserve "$source" "$target"
ls -la "$target"
stat "$target"

rm -f "$target"

echo
echo "Target (rsync): \"$target\""
rsync --archive "$source" "$target"
ls -la "$target"
stat "$target"

... perhaps? Thanks for your effort, highly appreciated.

[Nicholas Neumann (aggienick02)]

So just to make sure I was clear, "fixing" the client to send cleaner messages does avoid the problem. But (imho) the real issue is on the server, since other servers can deal with the less clean messages just fine, and there's nothing wrong (again, imho) with the less clean messages.

Is that uname -r, etc, on your client machine?

A script to test all of this is a good idea. I started with what you put and tried to simplify it a bit. This is where I ended up:

#!/bin/bash

source_path=/tmp/mod_time_test_file
target_path=/media/rn214/user/Temp/mod_time_test_file

rm "$source_path"
rm "$target_path"
echo abcd > "$source_path"

#Set date to January 1 2020 at 12:34.56 PM
touch -t "202001011234.56" "$source_path"

cp -p "$source_path" "$target_path"

echo "Copy complete; sleeping 10 seconds before stat"
#We sleep, as smbd actually does work after the cp -p returns.
#An immediate stat may return the current time for the modified timestamp
#even though it will be corrected shortly
sleep 10

source_time=$(stat -c "%y" "$source_path")
target_time=$(stat -c "%y" "$target_path")

echo "Source modtime: $source_time"
echo "Target modtime: $target_time"

if [ "$source_time" = "$target_time" ]; then echo "PASS: Modtime preserved"; else echo "FAIL: Modtime not preserved"; fi

[Nicholas Neumann (aggienick02)]

Oooh, now it gets exciting. You mentioned you were using the RN214, which runs Netgear ReadyNAS, which appears to be based on a pretty old version of Debian. So I fired up an Ubuntu 15 VM and created an SMB share on it. The bug reproduces there...

That gives us a server environment where we can fully debug things, as opposed to the constrained Synology environment where many tools are unavailable. I'm happy. :-)

[Mint Platz (mintplaetzchen)]

OK, ran the script on my end, result was:

Copy complete; sleeping 10 seconds before stat
Source modtime: 2020-01-01 12:34:56.000000000 +0100
Target modtime: 2020-01-01 12:34:56.000000000 +0100
PASS: Modtime preserved

Client:
Kernel Linux 6.5.0-14-generic
Operating System: Linux Mint 21.2
SAMBA: Version 4.15.13-Ubuntu

And, as luck would have it: Surely enough I have full root ssh access to the NAS box. Sooo (after converting my priv key to something putty could digest):

Server:
Kernel: Linux 4.4.218.alpine.1
Operating System: ReadyNASOS 6.10.8
SAMBA: Samba version 4.8.0 (running protocol SMB3_11)

Hope that helps your investigation. If there's anything I should post over there at https://community.netgear.com, just tell me.

[Nicholas Neumann (aggienick02)]

Awesome, thanks for the help. Could you run samba -V on the server to see the samba version running there?

And then on the client, could you run:

cat /proc/mounts

and find the line with your share to see what version of the SMB protocol it ended up using?

(It'll be a line like:
//10.0.234.59/sambashare /media/ubuntu22btrfs_sambashare cifs rw,relatime,vers=3.1.1,cache=strict
)

If you have the time and can run the same script but changing "cp -p" to "rsync -t" that would be really helpful too. This morning I started finding scenarios where one of "cp -p"/"rsync -t" would fail but not the other, depending on protocol.

(Thought I was losing my mind this morning b/c one of my reliable reproducers had stopped - turned out I had changed the SMB protocol version on the client to see if it affected my other reproducer - it didn't, so I forgot I had changed it.)

[Mint Platz (mintplaetzchen)]

cat /proc/mounts gives me something like:

//rn214/user /media/rn214/user cifs rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=user,domain=DOMAIN,uid=1000,noforceuid,gid=1000,noforcegid,addr=10.1.2.3,file_mode=0770,dir_mode=0770,iocharset=utf8,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1 0 0
(slightly anonymized)

the other entries look very similar, i. e. with vers=3.1.1.

They originate from such entries in /etc/fstab:
//rn214/user /media/rn214/user cifs noauto,users,credentials=/home/user/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0

On the rn214 typing samba -V gives me:
-bash: samba: command not found
, hence I pasted the result of smbstatus as root. There it said:
Samba version 4.8.0

The script with rsync instead of cp executed with unspectacular results:
Source modtime: 2020-01-01 12:34:56.000000000 +0100
Target modtime: 2020-01-01 12:34:56.000000000 +0100
PASS: Modtime preserved

So this exact version of SAMBA on my particular version of Linux Mint Mate with that particular the Ubuntu Kernel with the aforementioned SMB mounts connected to a D-Link DGB-108 talking to that particular NetGear NAS with exactly that version of Linux 4.4.218.alpine.1/ReadyNASOS 6.10.8 seem preserve the modification time stamp at least for the two test instances covering the exact same parameters of rsync and cp.

If that sounds a bit sarcastic: Yeah, intentionally so. For sure does not raise my confidence in allowing future updates. Eat that, Linux lovers!

[Nicholas Neumann (aggienick02)]

Interesting. Can you run "apt-get -s install cifs-utils" on your client to see what version of cifs-utils you have installed?

[Mint Platz (mintplaetzchen)]

Output of apt-get -s install cifs-utils:
cifs-utils is already the newest version (2:6.14-1ubuntu0.1).

Same for SAMBA:
samba is already the newest version (2:4.15.13+dfsg-0ubuntu1.5).

Hope that helps.

[Nicholas Neumann (aggienick02)]

Thanks for sharing that. Your cifs-utils is the same that I have on an ubuntu 22 VM, which shows the issue with a server running an earlier version of Samba (4.7.x) and a later version. I unfortunately don't readily have a VM with 4.8.x readily available, but the brittleness of file modtime preservation depending on client and server is surprising, and I can understand the sarcastic comment! :-)

[Mint Platz (mintplaetzchen)]

Is there anything anyone would want to know (or must be told), so we can anticipate these kinds of issues with Linux/the Kernel/Mint/ReadyNAS/NetGear/Ubuntu/Debian/Synology/SAMBA/cifs in the future and prevent another regression ruining all my or any other users' timestamps next time we run a rsync backup on our NAS after a software update? Or is this just another case of "different interpretation of standards leading to potentially unwanted results"?

I'm not very familiar with the intricacies of Linux neither the respnsibilities of its software development community and release cycles, but if you want me to pass those findings (with a brief description of what exactly is happening, where and when) to anyone I'll try my best.

Because when you're saying "ubuntu 22 VM, which shows the issue with a server running an earlier version of Samba (4.7.x) and a later version", I understand this as "if things work as they should, we're somehow in a sweet spot within versions now and any update can break functionality again.". Which is not exactly something I'm looking forward to in an operating system.

Thanks for your support, highly appreciated.

[Nicholas Neumann (aggienick02)]

Unfortunately I don't feel like I have enough understanding of why things are working for you given the versions you are dealing with. The whole thing seems like a complex compatibility matrix of client version, server version, and negotiated SMB protocol version. I've seen enough code changes and similar problems to now have validating timestamp behavior on my to-do checklist on any server (Samba) or client (cifs-utils) version upgrade.

In general I would say the more recent you are with both, the more likely it seems that modtimes will work. In my limited experience, the latest cifs-utils emitted significantly cleaner SMB requests when preserving modification times.

[Nicholas Neumann (aggienick02)]

I kept digging into my specific issue, and now have to add a 4th dimension to the matrix of variables to consider that can affect modtime preservation: Samba configuration values. Here are the details.

For my issue, modtimes are not preserved on Synology devices due to the Synology's default SMB Advanced Setting in the "Others" section of its UI, "Synchronize data to drive immediately upon SMB client request"

This preference controls the smb "strict sync" configuration value. It was changed from False to True 6 years ago in Samba 4.7.0: https://gitlab.com/samba-team/samba/-/commit/ed483d8e570700a303e11bc03d6250cd0ae4aaed

Synology devices still default this value to False though. Unfortunately, the False value causes a Samba bugfix that helped with correct modtimes to not work. This bugfix is here: https://gitlab.com/samba-team/samba/-/merge_requests/1210/diffs?commit_id=945158c7652bd0580828fb620afc722bc8a05967 .

Unfortunately that bugfix does not work when strict sync is disabled, because smbd_smb2_flush_send checks lp_strict_sync and returns early instead of setting the smbd_smb2_flush_done callback to run; smbd_smb2_flush_done is where one of the modtime-related fixes was made.

(I've double validated that it is this setting that makes the difference. Setting it to True on the Synology device causes modtimes to be preserved. Setting it to False on an Ubuntu VM that was preserving modtimes causes it to stop.)

I passed this info on to Synology in case they are interested in changing the default value to match what Samba defaults to. I'll also mention the issue with the Samba bugfix for modtimes to the Samba project in case they are interested.