我在设置基于生产服务器克隆的开发服务器时遇到问题。我们使用CMS，似乎它的某些脚本存在权限问题。为了深入了解它，我们设置了一个PHP脚本来测试权限，并进入终端以比较其结果。
我们的测试脚本如下
//try one of the essential folders of the CMS
$path= '[our_base_dir]/html/cms/content'
echo $path.' is'.(!is_writable($path) ? ' NOT' : '').' writable.<br/>';
哪些打印
[our_base_dir]/html/cms/content is NOT writable.
但是，当进入终端时，我不明白为什么会这样。这是它的输出：
$ getfacl content
# file: content
# owner: cchapman
# group: cchapman
user::rwx
user:apache:rw-
group::rwx
mask::rwx
other::r-x
和
$ grep 'cchapman' /etc/group
cms:x:510:cchapman,apache
cchapman:x:512:cms,apache
我相信apache用户是需要具有写入访问权限的用户，而cms和cchapman用户只是文件所有者，具体取决于它们的创建方式。在任何情况下，这三个都应该能够根据组权限读取和写入彼此的文件。
这在文件级别和目录级别都是相同的。我唯一的想法是，在文件级别处理Apache用户的方式出了问题。难道是这样？或者还有什么会授予不同的访问权限？
我怀疑我的评论实际上是答案，所以我会把它作为一个发布：
通过在路径字符串 /html/cms/content 上调用 is_writable 来检查绝对路径/html/cms/content是否可写。我相信你想要的是：
$path = realpath('./html/cms/content');//note the .
if (is_writable($path))
printf('"%s" is writable', $path);
如果您正在检查的路径确实是 /html/cms/content ，这对我来说似乎很奇怪（我希望/var/www/base_dir/html/cms/content或其他什么），那么请确保获取realpath（即：没有符号链接等等）。所以总是调用realpath（就像我在上面的片段中所做的那样）。
除此之外：您有一个apache用户，这很好，但您确定脚本是由该用户执行的吗？ www-data和nobody也很常见。检查实际运行代码的用户，并确保该用户也具有适当的权限。