我之前在Docker容器里也碰到过类似的权限坑，你已经排查了属主、权限和SELinux这些常见点，那咱们从几个容易被忽略的角度入手：

1. 检查目录的chattr特殊属性 #

有时候目录被设置了不可修改或仅追加的特殊属性，哪怕权限设成777也没法创建新文件。你可以在目标目录执行：

lsattr /srv/www/is/app/tmp/cache/persistent

如果输出里有i（immutable，不可修改）或者a（append-only，仅允许追加内容），那就是这个问题。用下面的命令移除对应的属性：

# 移除不可修改属性
chattr -i /srv/www/is/app/tmp/cache/persistent
# 如果是仅追加属性就用这个
chattr -a /srv/www/is/app/tmp/cache/persistent

2. 排查Docker挂载的文件系统限制 #

如果这个tmp目录是从宿主机挂载进来的，宿主机的挂载选项可能偷偷限制了创建文件的权限。比如挂载时不小心用了ro（只读），或者某些网络文件系统（比如NFS）有额外的权限管控。你可以在容器里查看挂载信息：

mount | grep /srv/www/is/app/tmp

如果看到挂载选项里有ro，那必须修改Docker run命令或者compose配置，确保挂载时用的是rw（读写）权限。要是用了NFS挂载，还得去宿主机端检查NFS共享的权限设置。

3. 确认路径上所有父目录的权限（别只看目标目录） #

虽然你说tmp及其子目录的属主都是www-data，但路径上的某个父目录可能权限有问题？比如某一层目录没给www-data进入的权限（目录的执行权限）。你可以用namei命令逐层检查：

namei -l /srv/www/is/app/tmp/cache/persistent

这个命令会列出路径上每一层的属主、权限信息，确保每一层目录对www-data都有读+执行权限（至少）——毕竟没有执行权限的话连目录都进不去，不过你已经能cd到目标目录，这个可能性偏低，但还是确认下更稳妥。

4. 测试容器内其他目录是否正常 #

你可以先在容器的系统临时目录（比如/tmp）用www-data身份创建文件试试：

su - www-data -c "touch /tmp/test_wwwdata_create"

如果这个操作能成功，说明问题就出在你那个特定的tmp目录上，回到前面的步骤排查；如果也失败，那可能是容器内www-data用户的配置有问题，比如被设置了受限shell，或者用户的umask值异常？可以执行su - www-data -c "umask"看看，如果umask是077之类的严格值，可能会影响文件创建，但你说权限设777都不行，这个可能性也不高。

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