Systemd服务启用DynamicUser后无法写入CacheDirectory的权限问题求助
我之前调试类似的systemd动态用户权限问题时踩过不少坑，结合你的描述和OpenSUSE的环境特性，给你几个排查和解决的方向：
一、先定位具体错误原因
先别瞎猜，先看systemd的详细日志，能帮你精准定位问题：
运行以下命令查看服务的报错详情：
journalctl -u bazel-remote.service -xe
重点看报错的具体信息，比如是Permission denied，还是提到了AppArmor/SELinux的拦截，这会直接指向问题根源。
二、排查安全模块的拦截（最可能的原因）
OpenSUSE默认启用了AppArmor安全模块，当使用DynamicUser=yes时，服务会以无特权的临时用户运行，AppArmor的默认规则可能会阻止它写入/var/cache下的目录，哪怕目录权限是对的。
检查AppArmor拦截记录：
- 查看AppArmor状态，确认是否有针对bazel-remote的规则：
aa-status
- 查看系统日志里的AppArmor拒绝记录：
dmesg | grep apparmor
如果发现有DENIED记录指向bazel-remote，那就是AppArmor的问题。临时禁用对应规则测试：
aa-disable /etc/apparmor.d/usr.local.bin.bazel-remote # 替换成实际的profile路径
重启服务如果正常了，就需要修改AppArmor规则，允许服务写入/var/cache/bazel-remote/**。
如果是SELinux（部分OpenSUSE版本可能启用），可以用以下命令查看拦截记录：
ausearch -m avc -ts recent
临时关闭SELinux测试：
setenforce 0
解决后再添加对应的SELinux上下文规则。
三、调整CacheDirectory的权限配置
虽然你说目录权限是755，但systemd默认创建CacheDirectory的权限可能继承了父目录的一些属性，试试显式指定目录权限：
在服务文件的[Service]段添加：
CacheDirectoryMode=0700
这样创建的目录只有动态用户自己有读写权限，避免可能的权限冲突或继承问题。
四、清除残留的旧目录重新创建
如果之前用固定用户运行过服务，/var/cache/bazel-remote目录可能残留了旧的ACL或文件属性，哪怕你改了所有者也可能有隐藏问题：
- 停止服务：
systemctl stop bazel-remote.service
- 删除旧目录：
rm -rf /var/cache/bazel-remote
- 重启服务，让systemd以动态用户的身份重新创建目录：
systemctl start bazel-remote.service
五、检查bazel-remote的内部配置
虽然你说用固定用户没问题，但还是确认下bazel-remote有没有设置特殊的文件权限或umask参数，比如有些服务会强制设置umask为022以外的值，导致动态用户创建文件时权限不足。
备注：内容来源于stack exchange，提问作者dieortin
