Syncthing同步过程中子目录权限继承问题分析

在Linux环境下使用Syncthing进行用户主目录同步时，管理员发现了一个关于文件权限继承的特殊现象。当配置了包含特定子目录或文件的同步规则时，目标文件的权限能够正确继承，但其上级目录的权限却未能按预期更新。

问题现象

某Linux系统管理员配置了以下同步排除规则：

!.ssh
!.config/gtk-3.0/bookmarks
.*

实际运行中发现：

• .ssh目录及其内部文件权限正确设置为glaudano:users
• 目标文件.config/gtk-3.0/bookmarks权限也正确继承
• 但上级目录.config和.config/gtk-3.0仍保持syncthing:syncthing的原始权限

技术背景

该问题出现在Syncthing 1.27.7版本中，运行用户为syncthing（属于syncthing组），并通过systemd单元覆盖启用了CAP_CHOWN和CAP_FOWNER能力。这种配置通常用于需要跨用户同步文件的场景，其中同步服务需要修改不属于自己的文件权限。

问题本质

经过分析，这属于Syncthing的权限同步逻辑缺陷。当同步包含特定子路径的文件时（如.config/gtk-3.0/bookmarks），程序会正确设置目标文件的权限，但未能递归处理其所有父目录的权限。这与常规的UNIX权限继承机制存在差异，在传统文件系统中，新建子目录/文件通常会继承父目录的权限设置。

解决方案

该问题已被确认为已知缺陷，与另一个已报告的问题具有相同根源。临时解决方案是：

1. 手动修改受影响父目录的权限
2. 等待官方修复版本发布
3. 考虑在同步规则中显式包含所有需要权限继承的父目录

最佳实践建议

对于需要精确控制权限的同步场景，建议：

• 在同步前确保目录结构已存在并设置正确权限
• 对关键目录设置明确的包含规则
• 定期检查同步后的权限一致性
• 考虑使用post-sync脚本进行权限修复

该问题预计在后续版本中修复，届时将实现完整的权限继承链同步功能。