SVN服务启动或运行时出现“Permission denied”错误，导致日志无法写入，其根本原因往往并非日志文件本身的权限问题，而是运行svnserve的用户或用户组对日志所在目录没有写入权限，或目录缺少执行权限（x）而无法进入。要彻底解决这个问题，需要从进程身份、路径权限、安全模块三个方面进行排查与修复。
确认svnserve实际运行用户与日志路径归属
日志写入失败，首先要明确是谁在写入以及写入到哪里：
- 查看进程：执行
ps aux | grep svnserve，观察USER列，例如显示svn或root - 检查日志配置：打开
svnserve.conf（通常位于仓库的conf/目录下），确认是否启用了日志（如log-file = /var/log/svn.log）；若未指定，svnserve 默认不写日志，报错可能来自其他组件（如 Apache + mod_dav_svn） - 检查路径归属：执行
ls -ld /var/log和ls -ld /var/log/svn.log（或你配置的日志路径），确认目录的所有者、所属组以及权限位是否允许该用户写入
修复日志目录与文件的属主和权限
即使文件权限设置为644，如果目录不可写或不可执行，写入依然会失败：
- 确保日志目录（例如
/var/log）对 svn 用户同时具备 w 和 x 权限：典型的安全配置为drwxr-s---（即775或2775），此时 svn 用户需属于该目录的所属组（如adm或svn） - 执行：
sudo chown -R svn:adm /var/log/svn*（假设日志文件前缀为 svn） - 执行：
sudo chmod 775 /var/log（仅用于临时测试），更推荐加上SGID位：sudo chmod 2775 /var/log，并确保 svn 用户已加入 adm 组：sudo usermod -aG adm svn - 日志文件本身建议设置为
644或664，避免使用 444 或 600（否则非 root 进程无法写入）
检查SELinux或AppArmor是否拦截写入
Linux发行版通常默认启用强制访问控制，它会覆盖传统的权限设置：
- CentOS/RHEL：运行
sestatus，若显示enforcing，可先临时设为宽容模式验证：sudo setenforce 0，然后重启 svnserve 测试日志是否可写入 - 若恢复写入，说明是 SELinux 拦截，需正确打标签：
sudo semanage fcontext -a -t var_log_t "/var/log/svn.*"，再执行sudo restorecon -v /var/log/svn* - Ubuntu/Debian：检查
dmesg | grep -i avc或sudo journalctl | grep -i apparmor，确认是否有拒绝记录；必要时调整 AppArmor 配置或临时禁用对应策略
验证父目录的执行权限是否完整
日志路径中任意一个上级目录缺少 x（执行）权限，都会导致“Permission denied”——不是因为无法写入，而是根本无法进入该路径：
- 例如日志路径为
/var/log/svn/svn.log，需要逐层检查：/var、/var/log、/var/log/svn各自的权限 - 每一层都必须对 svn 用户具有 x 权限；若某一层权限为
drw-r--r--（即644），则 svn 用户无法 cd 进入，自然无法创建或写入日志文件 - 修复命令示例：
sudo chmod 755 /var/log/svn（确保包含 x 权限），再执行sudo chown svn:adm /var/log/svn
