WordPress 迁移后，前台可以正常访问，后台却提示“无法创建目录”，或安装插件时要求填写 FTP 账号。这通常说明文件读取已经恢复，更新流程所需的文件操作条件仍未满足。问题可能涉及迁移后保留的 UID、PHP 运行账号、目录权限，也可能来自只读挂载、空间不足或主机的部署策略。
不要直接给整个站点设置 777，也不要把 FS_METHOD=direct 当成通用修复。 它不会替 PHP 获得文件系统权限，强制直写还可能绕过原本的所有权检查。[1][2]
本文主要面向 Linux、PHP-FPM 与自管 WordPress 环境。示例站点为 /srv/www/example，PHP 站点账号为 siteuser，均须替换。共享主机、托管 WordPress、容器和只读部署，应遵循平台的账号隔离与发布规则，不要按示例修改所有权。
先记录失败发生在哪一步
插件安装可能依次涉及下载、写入临时文件、解压、创建插件目录和复制文件。不同报错需要检查不同位置。
| 现象 | 优先检查 |
|---|---|
| 要求 FTP 或连接凭据 | WordPress 文件系统方法、所有权检测及主机策略 |
| 无法创建目录、无法复制文件 | 报错路径的属主、权限、父目录、ACL 与安全策略 |
| 下载失败、证书或网络错误 | PHP 出站访问、DNS、TLS 信任与下载源 |
| 解压失败、没有足够空间 | 压缩包、临时目录、空间、inode 与用户配额 |
| 没有安装入口或提示操作被禁止 | 用户权限、多站点规则、DISALLOW_FILE_MODS 等配置 |
记录完整报错、路径和时间，查看对应站点的 PHP-FPM、Web 与系统日志。不要为了收集错误把详细调试信息公开输出到前台。一次只复现一个操作，避免多名管理员同时更新。
变更前准备文件与数据库备份，并确认能恢复；同时记录待修改目录的属主、组、权限及 ACL。权限修改的回退需要这些信息，重新复制一份配置文件并不能恢复目录元数据。
查清 PHP 用哪个账号操作文件
Nginx worker 用户、SSH 登录用户与 PHP-FPM worker 用户可能不同。以实际站点对应的 FPM 池配置和工作进程为准，不能因为服务器上有 www-data 就认定所有站点都使用它。
ps -eo user,group,pid,args | grep '[p]hp-fpm'
stat -c '%U:%G %u:%g %a %n' /srv/www/example /srv/www/example/wp-content /srv/www/example/wp-content/plugins
namei -l /srv/www/example/wp-content/plugins
FPM 主进程可能由 root 运行，真正执行站点请求的是池工作进程。迁移保留了数值 UID/GID，而新服务器账号编号不同，也可能造成“文件名字看着对，权限却对不上”。将数值 ID 与目标站点账号对应检查。
namei -l 可逐级查看路径权限。即使 plugins 目录可写，上层目录缺少路径穿越所需的执行权限，也会导致访问失败。符号链接还可能指向另一个挂载或发布目录，修改前应解析实际路径，并确认它属于本次站点。
在支持 sudo 的自管环境，可按实际账号做有限检查：
sudo -u siteuser test -w /srv/www/example/wp-content/plugins
printf 'write-test exit=%s\n' "$?"
返回 0 表示该账号在当前命令环境下认为目标可写，但不能覆盖 PHP-FPM 的全部限制。SELinux、AppArmor、open_basedir、容器命名空间和只读挂载仍可能导致实际请求失败。不要用公开的 phpinfo 页面排错后忘记移除。
文件权限和 WordPress 的直写判断要分开看
WordPress 通过 Filesystem API 选择 direct、FTP 等文件操作方式。[2] 默认方法选择包含所有权方面的安全判断，因此操作系统层面某个目录可写，不保证后台一定选择直写。FTP 提示本身也不能证明服务器上应当安装 FTP 服务。
先查看 wp-config.php 是否已经定义 FS_METHOD，以及主机是否通过其他机制控制文件操作。不要把配置文件中的数据库密码和密钥发到公开渠道。
常见的 755 目录、644 文件只是一组权限示例：目录 755 允许属主写入；文件 644 同样只有属主能写。如果文件归部署账号所有，PHP 账号不同，这组数字本身不会授予 PHP 更新能力。
反过来，把所有代码都交给 PHP 账号，也会让应用漏洞更容易改写代码。需要先决定站点采用哪一种管理方式：[1]
- 允许后台维护的单站点：按平台设计给站点专用账号必要的目录与文件操作权限。
- 代码由流水线发布：插件通过受控部署更新，后台代码写入被限制可能是预期行为。
- 多站点共享服务器：保留账号隔离，不要把各站点统一归到公共 Web 用户。
安装新插件需要创建目录，更新已有插件还可能涉及暂存、覆盖或替换目录。只让 plugins 根目录可写，不一定足以更新原先由其他账号部署的插件文件。
修复限定到已确认的站点和目录
如果确认该站点允许后台安装、PHP 池账号确实为 siteuser，且 plugins 目录按既定设计应由它管理，可在备份和维护窗口后修正该目录本身：
# 示例只修改目录本身，不递归修改整个站点
sudo chown siteuser:siteuser /srv/www/example/wp-content/plugins
sudo chmod 0755 /srv/www/example/wp-content/plugins
这不是完整安装保证。已有插件子目录、更新暂存目录和实际使用的临时目录仍需逐项检查。需要递归修复时，应先明确范围、排除共享目录和符号链接、保存元数据，再按当前部署模型制定方案；不要直接执行全站 chown -R 或统一 chmod -R 755。后者还会错误改变普通文件的执行位。
如使用组权限或 ACL，应同时确认 FPM 进程的实际组成员、默认 ACL、掩码和新文件继承规则。对组成员的变更可能需要按运维流程重启或重载相关工作进程。Windows ACL、NFS 和容器卷权限另有边界。
FS_METHOD 是配置选择，不是提权工具。只有已经确认平台支持直写、目录所有权与安全模型合理时，才评估是否需要显式设置；多数场景应先修正底层问题。若平台规定通过 FTP/SFTP 或部署系统更新，应使用其支持的方法，并核实相应传输实现，不要把明文 FTP 暴露到公网来消除提示。
权限看似正常，继续检查这几层
df -h /srv/www/example/wp-content
df -i /srv/www/example/wp-content
findmnt --target /srv/www/example/wp-content -o TARGET,SOURCE,FSTYPE,OPTIONS
磁盘容量、inode、用户配额任一耗尽，都可能阻止新文件创建。目录挂载为只读、容器使用只读根文件系统，修改 chmod 无法解决。不要直接改成读写挂载，应先确认只读是部署设计还是底层故障。
安装流程也可能依赖 PHP 临时目录、WordPress 更新暂存位置或显式配置的 WP_TEMP_DIR。从实际错误路径和配置判断，不要凭想象新建一个全局可写目录；临时位置应避免不必要的公网访问并具备正确清理策略。[3]
SELinux 启用时，需检查审计日志与文件上下文是否符合站点目录用途。AppArmor、PHP open_basedir 或主机安全策略也可能阻止操作。修复应调整被确认的策略或上下文，不能以关闭 SELinux、关闭所有安全插件作为长期方案。
还要检查 DISALLOW_FILE_MODS。它用于限制插件、主题安装更新等文件修改，而 DISALLOW_FILE_EDIT 主要控制后台文件编辑器，两者不能混为一谈。[3] 多站点的安装权限通常由网络管理控制；托管平台主动锁定更新入口时，应联系平台确认维护方式。
用一次受控安装完成验收，再恢复业务
修复后，在测试环境或维护窗口安装已审核、来源可信且兼容当前版本的插件。只验证安装不等于必须启用，启用可能执行数据库变更和其他业务动作，应单独审批。
检查安装结果、文件属主与权限、日志和已有页面，再确认临时文件没有异常积压。若还涉及已有插件更新，需另行验证更新与回退；新插件安装成功不代表旧文件覆盖权限也已经正常。
测试结束按计划移除不再需要的插件，确认不会误删业务数据，并检查目录没有变成全局可写。若修改带来异常，应恢复记录中的属主、组、模式或 ACL；不要用另一套统一权限覆盖原有元数据。插件更新涉及数据结构变化时，旧文件回滚可能不足以恢复，需采用已验证的整站恢复方案。
前台能访问只能说明读取路径基本可用。迁移验收还应覆盖后台安装、上传和计划任务，并明确今后由后台还是部署系统负责更新。把维护方式与权限模型对齐，才能避免下一次迁移再次出现 FTP 提示。
参考资料
资料核验日期：2026 年 10 月 23 日。命令为说明性示例，本文未声称已在读者生产环境实测。