Rsync守护进程权限异常排查请求（手动执行命令正常）

你提到手动执行rsync完全正常，但通过UHS_FolderMonitor.service或rsyncd守护进程运行时出问题，且推测核心是守护进程运行用户的权限问题，这个方向非常准确，咱们一步步拆解验证：

1. 先确认rsyncd的实际运行身份 #

虽然你说守护进程以root启动，但rsyncd配置可能会覆盖启动用户，得核实：

• 查看当前rsyncd进程的有效用户：

  ps aux | grep rsyncd
  

• 检查/etc/rsyncd.conf中的用户配置，这会直接决定rsyncd的运行身份：

  grep -E "uid|gid" /etc/rsyncd.conf
  

如果配置了非root的uid/gid，这个用户必须具备访问源目录、目标目录（包括NFSPRODW挂载点）的完整权限。

2. 验证systemd服务的运行上下文 #

UHS_FolderMonitor.service由systemd管理，要确认它的运行用户及安全限制：

• 查看服务文件的用户配置：

  grep -E "User|Group" /etc/systemd/system/UHS_FolderMonitor.service
  

• 如果没配置用户，默认会以root运行，但systemd的安全参数（比如ProtectSystem、PrivateTmp）可能会限制进程访问某些目录，尤其是NFS挂载的NFSPRODW，得检查服务文件里有没有这类限制项。

3. 脚本与目录权限的细节验证 #

针对你提到的UHS_FolderMonitor.ksh和NFSPRODW，重点确认：

• 脚本本身的权限：执行ls -l /usr/etc/UHS_FolderMonitor.ksh，确保运行用户有执行权限（x位），且脚本所在目录有访问权限（r位）。
• NFSPRODW挂载点权限：执行ls -ld /path/to/NFSPRODW（替换为实际路径），确认运行用户（rsyncd或服务用户）有对应权限（同步到NFS要写权限，同步出来要读权限）。
• 注意NFS服务器端的权限！NFS共享的/etc/exports如果配置了root_squash，会把客户端的root用户映射为nobody，这会直接导致root在客户端访问NFS时权限失效，得检查服务器端的exports配置是否有no_root_squash参数。

4. 从日志里抓具体错误 #

/var/log/rsync_activity.log是定位问题的关键，直接提取权限相关错误：

grep -i "permission|denied|error" /var/log/rsync_activity.log

如果日志显示“permission denied”，结合前面的用户配置，就能精准定位是哪个用户访问哪个目录时出了问题。

5. 模拟守护进程用户执行脚本 #

为了100%验证权限问题，咱们可以切换到rsyncd或服务的运行用户，手动执行脚本，看是否能重现问题：

• 如果rsyncd用了uid=nobody，执行：

  su -s /bin/bash nobody -c "ksh /usr/etc/UHS_FolderMonitor.ksh"
  

• 如果服务用了特定用户，同理切换到该用户执行脚本，观察输出的错误信息。

补充：rsync命令的环境差异 #

手动执行和守护进程执行的rsync可能存在环境差异：

• 手动用的是本地rsync，还是rsync daemon模式（rsync://）？
• 脚本中的rsync命令是否指定了--rsync-path或其他参数，导致守护进程环境下找不到命令或权限不足？

内容的提问来源于stack exchange，提问作者fball4life36