Comment 34 for bug 2007055

Revision history for this message
Mint Platz (mintplaetzchen) wrote :

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!