核心问题是svnserve运行用户对日志目录缺乏写入及执行权限，需确认进程用户、统一日志路径属主属组（如svn:adm）、确保各级目录具备x权限（如755/2775），并检查selinux/apparmor拦截。
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
