NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.

Forum Discussion

VolkerB's avatar
VolkerB
Aspirant
Feb 04, 2024

Modification time preservation issue using SMB in certain configurations with ReadyNASOS 6

Hi!

 

I ran across a quite weird behaviour where modification time stamps of the local file system were not preserved after copying the file to a SMB share on my Netgear ReadyNAS 214 from a Linux client. After copying, the file received the current time as modification time instead. That behaviour seems to depend on certain versions of the client SMB version, the server SMB version and the negotiated SMB protocol version.

 

Why is that an issue? Because mirroring directories with rsync with the strategy to overwrite older files does not work properly anymore.

 

In a nutshell you would expect a file to look identical in terms of stat -c <the_file> on client and server after copying with either cp -p or rsync -t.  On my system using Linux Mint Mate 21.2 that was not the case against a RN214 running ReadyNASOS 6.10.8 with Linux 4.4.218.alpine.1 kernel and Samba version 4.8.0 (running protocol SMB3_11). Updating the client(!) kernel to Linux 6.5.0-14-generic then fixed it. Tendentially, more recent SMB versions seem to expose cleaner behaviour.

 

Read all the gory details at bugs.launchpad.net/ubuntu.

 

To find out, if your system is affected, I suggest creating and running this shell script (sorry for the messy formatting, the forum software does not seem to let me properly paste a raw text file as "code sample"):

 

#!/bin/bash
# Shell script to verify SMB timestamp integrity.
# Changelog:
# 1.0: Initial Linux release.
version="1.0"

 

# Directories.
source_dir=~/Temp
target_dir=/media/rn214/user/Temp

 

# Sleep duration [s].
sleep_duration=10

 

# Color codes.
RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m' # No Color

 

# Show usage information.
usage() {
echo "Usage: ${0##*/} [source_dir] [target_dir]"
echo "Creates temporary file at [source_dir], copies it over to [target_dir] with 'cp -p' and 'rsync -t',"
echo "then compares timestamps of source and target file."
echo "Defaults:"
echo " source_dir=$source_dir, target_dir=$target_dir."
exit 1
}

 

# Show client system details.
sysdetails() {
echo "Client system details:"
hostnamectl
echo "Kernel:"
uname -r
echo "Samba version:"
samba -V
echo "Please run 'hostnamectl', 'uname -r' and 'samba -V' (or 'sudo smbstatus') on your SMB server to determine versions."
}

 

# Strip off path from filename.
strip_path() {
filename="$1"
filename_without_path="${filename##*/}" # Strip off path.
echo "$filename_without_path"
}

 

echo "This is ${0##*/} V. $version, a tool to verify SMB timestamp integrity."

if [ "$1" == "-h" ] || [ "$1" == "--help" ]; then
usage
fi
if [ "$1" != "" ]; then
source_dir="$1"
fi
if [ "$2" != "" ]; then
target_dir="$2"
fi
if ! [ -d "$source_dir" ]; then
echo "Error: Source directory '$source_dir' does not exist."
exit 2
fi
if ! [ -d "$target_dir" ]; then
echo "Error: Target directory '$target_dir' does not exist."
exit 3
fi

 

temp_file="$(strip_path "$(mktemp -u)")"
source_path="$source_dir/$temp_file"
target_path="$target_dir/$temp_file"

 

echo "Creating '$temp_file' file at: '$source_dir'..."
rm -f "$source_path" &>/dev/null
rm -f "$target_path" &>/dev/null
head -c 1k </dev/urandom >"$source_path"
touch -t "202001011234.56" "$source_path"

 

echo
echo "cp -p $source_path $target_path..."
cp -p "$source_path" "$target_path"
echo "cp complete; sleeping $sleep_duration second(s) 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 $sleep_duration

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 -e "${GREEN}cp PASS: Modtime preserved.${NC}";
else
echo -e "${RED}cp FAIL: Modtime not preserved!${NC}";
sysdetails
fi
rm -f "$target_path" &>/dev/null

 

echo
echo "rsync -t $source_path $target_path..."
rsync -t "$source_path" "$target_path"
echo "rsync complete; sleeping $sleep_duration second(s) before stat..."
sleep $sleep_duration

target_time=$(stat -c "%y" "$target_path")
echo "Source modtime: $source_time"
echo "Target modtime: $target_time"
if [ "$source_time" = "$target_time" ]; then
echo -e "${GREEN}rsync PASS: Modtime preserved.${NC}";
else
echo -e "${RED}rsync FAIL: Modtime not preserved!${NC}";
sysdetails
fi

 

echo
echo "Cleaning up..."
rm -f "$source_path" &>/dev/null
rm -f "$target_path" &>/dev/null

echo "Done. Thank you for using ${0##*/}."

 

Adapt source_dir and target_dir accordingly. If you get mismatches, unfortunately there is no guaranteed recipe for success, as all kernels and SMB version react differently. Perhaps rather use NFS shares if you do not have to operate in a mixed environment.

 

I also cannot tell if Windows clients are affected as well and which version of Microsoft Windows would that be.

3 Replies

Replies have been turned off for this discussion
  • StephenB's avatar
    StephenB
    Guru - Experienced User

    VolkerB wrote:

     

    I ran across a quite weird behaviour where modification time stamps of the local file system were not preserved after copying the file to a SMB share on my Netgear ReadyNAS 214 from a Linux client. After copying, the file received the current time as modification time instead. That behaviour seems to depend on certain versions of the client SMB version, the server SMB version and the negotiated SMB protocol version.

     

    Why is that an issue? Because mirroring directories with rsync with the strategy to overwrite older files does not work properly anymore.

     


    Have you tried enabling rsync on the share, and making the share the rsync target (instead of mounting it with SMB)? That works with my own NAS->NAS backups with no issues.

     

    FWIW, I don't think Netgear will update SAMBA on the NAS, unless a security update requires them to do so.  Even then, they might just back-port the security fix.  They've clearly exited their NAS business.

    • VolkerB's avatar
      VolkerB
      Aspirant

      Please excuse the brevity, wresting the forum frontend is not exactly my forte.

       


      StephenB wrote:

      VolkerB wrote:

       

      I ran across a quite weird behaviour where modification time stamps of the local file system were not preserved after copying the file to a SMB share on my Netgear ReadyNAS 214 from a Linux client. [...]

      Why is that an issue? Because mirroring directories with rsync with the strategy to overwrite older files does not work properly anymore.


      Have you tried enabling rsync on the share, and making the share the rsync target (instead of mounting it with SMB)? That works with my own NAS->NAS backups with no issues.

       

      FWIW, I don't think Netgear will update SAMBA on the NAS, unless a security update requires them to do so.  Even then, they might just back-port the security fix.  They've clearly exited their NAS business.


      No, I didn't try rsync directly but I'm quite sure it would work. However in my case I need mounts to be accessible on demand, hence I have something like

       

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

       

      in fstab and added

       

      [public]
      # This share allows anonymous (guest) access to /home/public without authentication
      # Created with bindfs in /etc/fstab with
      # /home/public /media/public fuse.bindfs perms=0777,create-with-perms=0777 0 0
      comment = Public share. Everyone can read and write.
      path = /media/public
      read only = no
      guest ok = yes
      guest only = yes

       

      to smb.conf.

       

      Pity to hear that Netgear will discontinue it's NAS boxes, I found the RN214 to be among the better ones on the market. I'll continue to use it "as is" (it's behind a firewall anyway and not allowed to talk to "the internet") and hope that future client updates won't break anything. My post was just meant to sensitize people to look for weird things with timestamps when they copy files to a SMB share on a ReadyNAS.

       

       

      • StephenB's avatar
        StephenB
        Guru - Experienced User

        VolkerB wrote:

         

        Pity to hear that Netgear will discontinue it's NAS boxes, I found the RN214 to be among the better ones on the market. I'll continue to use it "as is" (it's behind a firewall anyway and not allowed to talk to "the internet") and hope that future client updates won't break anything. 

         


        FWIW, I am also planning to continue to use mine "as is" as long as they work.  Mine are just used for storage, so also not exposed to internet traffic.

         

NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology! 

Join Us!

ProSupport for Business

Comprehensive support plans for maximum network uptime and business peace of mind.

 

Learn More