Problem with rsync mtime preservation since update to kernel 6.17.13-6-pve

Hello,

it seems I see a problem with my proxmox based nfs server (on host) on a zfs volume in conjunction with a nfs-client using rsync.
Once a month I copy some files with rsync -avxAHX from some place to a nfs-mounted fs coming from a proxmox nfs-server exporting a zfs volume.
This has never happened before. I came across because I stopped the rsync by CTRL-C thinking that I can continue later on. But I found out that restarting the rsync copied all files again, even those already transferred earlier. I looked at the details and found that the atime of all files already copied was the actual copy time and not the preserved time stamp from the remote rsynced files. During the rsync around 4-5 latest copies show the correct timestamp, but are all modified to current time of copy later on.
This behaviour is new and did not happen with earlier kernels. Can somebody elaborate the cause of this? I saw similar descriptions with SMB-exported zfs vols that seem to have the cause in some samba config. But I could not deduct so far what to do with nfs in this problem...
Thanks for ideas ...

PS: Trying the same rsync with a local fs as destination everything works as expected. The problem really only shows with nfs-mounted fs from proxmox nfs-exported zfs..

Last edited: May 2, 2026

Hi, @skraw
I wonder if you really mean atime... Though you wrote "atime" both in the subject and inside the post.
But by default, rsync's decision whether to copy a file or not, doesn't depend on atime. It depends on mtime (and the size).

From rsync(1):
" Rsync finds files that need to be transferred using a "quick check" algorithm (by default) that
looks for files that have changed in size or in last-modified time."

By default, rsync does not preserve atime. It would require -U option to keep it:

" --atimes, -U preserve access (use) times"

" --archive, -a
[...] Be aware that it does not include preserving ACLs (-A), xattrs (-X), atimes (-U), [...]"

You use rsync -avxAHX (without -U) so access time isn't preserved. Neither in the source file, nor in the destination file.

I've just verified this in a Kubuntu 22.04, kernel 5.15.0-43, rsync 3.2.3-8ubuntu3:

Bash:

$ stat log.txt  
  File: log.txt
  Size: 265             Blocks: 8          IO Block: 4096   regular file
Device: 1dh/29d Inode: 2035784     Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  999/ kubuntu)   Gid: (  999/ kubuntu)
Access: 2026-04-28 08:57:59.685828377 +0200
Modify: 2026-03-06 23:37:50.686966112 +0100
Change: 2026-04-23 19:42:42.813206055 +0200
 Birth: -

$ rsync -avxAHX log.txt test/
sending incremental file list
log.txt

sent 381 bytes  received 35 bytes  832.00 bytes/sec
total size is 265  speedup is 0.64

$ stat log.txt                
  File: log.txt
  Size: 265             Blocks: 8          IO Block: 4096   regular file
Device: 1dh/29d Inode: 2035784     Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  999/ kubuntu)   Gid: (  999/ kubuntu)
Access: 2026-05-02 11:08:59.437368182 +0200
Modify: 2026-03-06 23:37:50.686966112 +0100
Change: 2026-04-23 19:42:42.813206055 +0200
 Birth: -

$ stat test/log.txt  
  File: test/log.txt
  Size: 265             Blocks: 8          IO Block: 4096   regular file
Device: 1dh/29d Inode: 2753687     Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  999/ kubuntu)   Gid: (  999/ kubuntu)
Access: 2026-05-02 11:08:59.437368182 +0200
Modify: 2026-03-06 23:37:50.686966112 +0100
Change: 2026-05-02 11:08:59.437368182 +0200
 Birth: -

Note the original atime was 2026-04-28... and after rsync both the source and destination files have atime 2026-05-02...

Only after I have used also -U for rsyncing other example file, the destination file's atime is the same as the original atime (though now the source file's atime is updated, because rsync accessed the file):

Bash:

$ stat .bash_logout
  File: .bash_logout
  Size: 220             Blocks: 8          IO Block: 4096   regular file
Device: 1dh/29d Inode: 79          Links: 1
Access: (0644/-rw-r--r--)  Uid: (  999/ kubuntu)   Gid: (  999/ kubuntu)
Access: 2026-04-12 18:32:57.091642902 +0200
Modify: 2025-10-24 18:04:34.980312001 +0200
Change: 2025-10-24 18:04:34.980312001 +0200
 Birth: -

$ rsync -avxAHXU .bash_logout test/
sending incremental file list
.bash_logout

sent 345 bytes  received 35 bytes  760.00 bytes/sec
total size is 220  speedup is 0.58

$ stat .bash_logout
  File: .bash_logout
  Size: 220             Blocks: 8          IO Block: 4096   regular file
Device: 1dh/29d Inode: 79          Links: 1
Access: (0644/-rw-r--r--)  Uid: (  999/ kubuntu)   Gid: (  999/ kubuntu)
Access: 2026-05-02 12:01:52.964170356 +0200
Modify: 2025-10-24 18:04:34.980312001 +0200
Change: 2025-10-24 18:04:34.980312001 +0200
 Birth: -

$ stat test/.bash_logout
  File: test/.bash_logout
  Size: 220             Blocks: 8          IO Block: 4096   regular file
Device: 1dh/29d Inode: 2754365     Links: 1
Access: (0644/-rw-r--r--)  Uid: (  999/ kubuntu)   Gid: (  999/ kubuntu)
Access: 2026-04-12 18:32:57.000000000 +0200
Modify: 2025-10-24 18:04:34.980312001 +0200
Change: 2026-05-02 12:01:52.964170356 +0200
 Birth: -

Regarding why your rsync "copied all files again, even those already transferred earlier" - I don't know.
I just wanted to help sort out the details .

Ok, to make the story a bit simpler. You are right, the problem turns around mtime. But you seem wrong about the rest.
If I do an "ls -l"' on the source dir of the rsync I see some dates/times for every file. These are of course mtimes.
If I do the rsync as stated (-avxAHX) I see (before last update) the same timestamps in both source and destination dir with "ls -l".
This is always the case for _local filesystems_. If you restart an rsync it syncs/copies nothing, because timestamps and files are the same.
But now doing the same thing I see the actual copy date of each file in the destination dir, whereas I see the original timestamp in the source dir.
Consequently, if I restart the rsync it syncs/copies everything again. And that is the new problem.
You can search the net for "problem rsync not preserving timestamps" and find lots of hits all referencing cifs exported zfs filesystems.
But none referencing nfs exported zfs filesystems ...

PS: I edited the thread title to reflect mtime, not atime

Last edited: May 2, 2026

Now, I investigated the problem further and got the impression that the kernel on client and server side must have some influence. The problem arose after a proxmox kernel update. My client kernel with problems was 6.12.something. I had another box that nfs-mounted another zfs volume from the same proxmox and showed no problem. But this one is always up-to-date with all packages. So I updated the problem-box to 6.18.26-1-lts (arch linux) - and the problem is gone. So I have to state that the latest proxmox is not really backward compatible regarding nfs-exports of zfs volumes. It would be nice to share this info in some changelog, because I think others may fall over it, too.

And now the problem came back, again for no obvious reason. rsync on nfs-mounted zfs and the mtime is set to current time, which it is not if I do the same rsync on a local drive with ext4. Any ideas?

推荐订阅源

Proxmox Support Forum