rsync同步NFS挂载目录时为何未更新远程文件时间戳？

我来帮你拆解这个问题——之前折腾NFS+rsync的时候也踩过类似的坑，咱们一步步分析：

首先，先明确你看到的rsync输出<f..tp.....是什么意思：f表示这是一个文件，t是时间戳不匹配，p是权限有差异，所以rsync确实检测到了本地和远程文件的时间戳差异，并且打算同步修正。但同步完成后远程时间戳没变化，说明rsync尝试修改时间戳的操作失败了。

大概率是下面这几个原因导致的：

• 远程NFS挂载的权限限制
  远程的目标目录是NFS挂载的，你用user@remotehost这个用户连接后，有没有权限修改该挂载目录下文件的时间戳？比如：

  • NFS服务器的export配置里可能开启了root_squash（把root用户映射成匿名用户），如果你的rsync用户不是远程NFS挂载目录的所有者，就没权限修改文件的mtime；
  • 远程文件可能被设置了特殊属性，比如chattr +i（不可修改属性），不过你之前能scp上传，这个可能性较低；
  • 远程NFS挂载时用了noatime这类选项，但这只会影响访问时间，不影响修改时间，所以不是这个原因。

• rsync修改时间戳的逻辑限制
  因为你之前用scp传过文件，文件内容其实是一致的，rsync默认会尝试只修改时间戳和权限（而不是重新传输文件）。但如果远程NFS环境不允许修改mtime，这个操作就会静默失败——你看着rsync输出说要同步，但实际改不了。

• 本地NFS挂载的时间戳可靠性
  先确认本地NFS挂载的文件时间戳是正确的：比如本地挂载NFS时有没有异常选项导致mtime读取错误？不过你明确要同步本地的时间到远程，这个可能性相对低，但也可以用stat /path/to/files/somefile确认本地的mtime是否符合预期。

验证和解决方法 #

1. 手动测试远程修改时间戳：登录到远程机器，随便找个文件试试touch -m -d "2024-01-01 10:00" testfile，如果提示权限拒绝，那肯定是权限问题，需要调整NFS的export配置（比如加no_root_squash）或者改用有所有者权限的用户同步。
2. 加详细日志排查：用rsync -azvvi ...（多一个v）运行，查看详细输出，rsync如果修改时间戳失败会打印类似failed to set times on "/path/to/files/xxx": Permission denied的错误，直接定位问题。
3. 尝试提升权限同步：比如改用root用户执行rsync（rsync -azvi /path/to/files/ root@remotehost:/path/to/files），如果远程NFS允许root操作，大概率能解决权限问题。
4. 检查NFS挂载选项：远程挂载NFS时确保没有限制mtime修改的特殊选项，本地挂载也可以确认下用了timeo等保证时间同步的参数。

备注：内容来源于stack exchange，提问作者Daniel Klisiewicz