WordPress更新失败“无法创建目录”：别先chmod 777，按这7步修复

先说结论：WordPress 更新插件、主题或核心时提示“更新失败：无法创建目录（Could not create directory）”，通常不是安装包坏了，而是 PHP 进程对 wp-content、upgrade、plugins 或 themes 没有写权限；其次才是磁盘或 inode 已满、临时目录残留、文件系统只读，以及 SELinux 拦截。不要先把目录改成 777。正确做法是先确认写入者，再修复属主和最小必要权限。

下面是一套从判断原因、修复到验证的完整闭环。适用于自建 Linux 服务器、VPS、宝塔面板、1Panel、Nginx/Apache、PHP-FPM 等常见环境。虚拟主机用户没有 SSH 权限时，可以把诊断结果交给主机商处理。

一、这个报错到底表示什么

WordPress 更新时会先把压缩包下载到临时位置，再解压到 wp-content/upgrade，最后把文件复制到目标插件、主题或核心目录。任一步骤无法新建文件夹，后台就可能显示“无法创建目录”。

WordPress 官方文件权限文档明确指出，WordPress 为启用更新等功能，需要能够写入 wp-content；不同主机的 PHP 运行用户可能不同，因此不存在一条可以盲目复制到所有服务器的 chown 命令。

二、先备份，再确认是哪一层出了问题

1. 备份数据库和 wp-content

至少保留数据库、wp-config.php 和 wp-content。如果站点正在接单，先进入维护窗口，避免修复期间恰好发生订单、库存或插件更新。

2. 看报错里写的是哪个路径

报错路径	优先检查	常见原因
`wp-content/upgrade/插件名`	`wp-content/upgrade`	临时目录属主错误、残留文件、磁盘满
`wp-content/plugins/插件名`	`wp-content/plugins`	目标目录不可写、旧目录由其他用户上传
`wp-content/themes/主题名`	`wp-content/themes`	主题目录属主或权限不一致
`wp-content/uploads/年/月`	`wp-content/uploads`	上传目录不可写、磁盘或 inode 已满

三、SSH 下按顺序执行这 7 步

以下命令假设你已经进入 WordPress 根目录，也就是能看到 wp-config.php 的目录。请先用 pwd 和 ls 确认位置，不要在不确定的目录执行递归命令。

第 1 步：确认磁盘和 inode 还有空间

df -h
df -i

Use% 接近 100% 时，先清理备份、日志、缓存或无用压缩包。磁盘容量没满但 inode 100%，说明小文件数量耗尽，WordPress 同样无法创建目录。此时反复改权限不会有任何作用。

第 2 步：确认文件系统不是只读

mount | grep ' / '
touch wp-content/.write-test && rm wp-content/.write-test

如果 touch 返回 Read-only file system，这是挂载或磁盘故障问题，不是 WordPress 权限问题。先检查系统日志和磁盘状态，修复文件系统后再继续。

第 3 步：找出 PHP/网页进程实际使用的用户

ps aux | egrep '(php-fpm|apache2|httpd|openlitespeed|lsphp)' | head -20

常见用户可能是 www-data、nginx、apache、www，也可能是面板为每个网站创建的独立系统用户。共享主机或使用 suexec 的环境，PHP 通常以站点所有者身份运行。不要看见教程写 www-data 就照抄。

第 4 步：检查出错目录的属主、属组和权限

ls -ld . wp-content wp-content/upgrade wp-content/plugins wp-content/themes wp-content/uploads
namei -l wp-content/upgrade

namei -l 会把路径的每一级权限拆开，特别适合发现“最外层目录可写，但父目录没有执行权限”的情况。若某个目录不存在，先不要慌，WordPress 本来就会在更新时创建 upgrade。

第 5 步：只修复需要写入的目录属主

假设你的站点运行用户确实是 www-data，属组也是 www-data，可以把命令中的用户名替换为你刚刚确认的真实值：

sudo chown -R www-data:www-data wp-content

如果部署流程要求代码由 SSH 用户所有、PHP 只通过共享组写入，则应采用“站点用户 + Web 共享组”的方式，例如：

sudo chown -R deploy:www-data wp-content
sudo find wp-content -type d -exec chmod 775 {} \;
sudo find wp-content -type f -exec chmod 664 {} \;

这两种模型二选一，不要混用。WordPress 官方也强调，文件应该由实际管理账户或 WordPress 使用的账户/组拥有；共享主机上不一定应该把所有文件交给 Web 服务器用户。

第 6 步：恢复常见的安全权限

单站点服务器且 PHP 以站点所有者运行时，常见基线是目录 755、文件 644：

sudo find wp-content -type d -exec chmod 755 {} \;
sudo find wp-content -type f -exec chmod 644 {} \;

如果使用共享组写入，则目录通常需要 775、文件 664。官方文档也给出 suexec 环境目录 755/750、文件 644/640 的常见方案，并明确警告不要把上传目录永久设置为 777。

第 7 步：清理失败更新留下的临时目录

先确认没有更新任务正在运行，再清理 upgrade 内的临时文件。不要删除整个 wp-content：

sudo find wp-content/upgrade -mindepth 1 -maxdepth 1 -print
sudo find wp-content/upgrade -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +

如果 upgrade 不存在，可以创建并赋予与 wp-content 一致的属主：

sudo mkdir -p wp-content/upgrade
sudo chown www-data:www-data wp-content/upgrade
sudo chmod 755 wp-content/upgrade

四、仍然失败时，继续排查这 4 个边缘原因

1. SELinux 拒绝写入

CentOS、RHEL、Rocky Linux、AlmaLinux 等系统可能启用了 SELinux。文件权限看起来正确，却仍被安全上下文拦截时，先查看：

getenforce
sudo ausearch -m avc -c httpd --start recent

不要为了省事永久关闭 SELinux。应根据日志修复目录安全上下文或对应策略。WordPress 官方文档也提醒，SELinux 拒绝写入时，表象很像普通权限错误。

2. PHP 临时目录不可写

php -i | grep upload_tmp_dir
php -i | grep sys_temp_dir

如果临时目录不存在、磁盘满或 PHP-FPM 无权写入，安装包甚至无法完成上传与解压。修改 PHP 配置后记得重载对应的 PHP-FPM 服务。

3. wp-config.php 强制了错误的临时目录

grep -n "WP_TEMP_DIR" wp-config.php

如果路径已经迁移或目录被删除，应改成真实、可写且不对公网暴露的位置。

4. 插件或主题目录来自另一个部署用户

通过 FTP、Git、面板文件管理器和后台安装混合部署，很容易让不同目录归属不同用户。只改 wp-content 顶层权限不够，要检查实际报错的插件或主题目录。

五、修复后怎么验证才算完成

在 WordPress 后台重试更新，确认不再出现“无法创建目录”。
执行 ls -ld 检查新生成目录的属主，确保不会下一次又由错误用户创建。
打开前台、登录后台、上传一张测试图片，确认页面、登录和媒体上传均正常。
如果改过 PHP-FPM、Nginx、Apache 或 SELinux，检查错误日志中没有新的 permission denied。
删除测试文件并开启自动备份，再恢复更新计划。

六、最常见的错误做法

整站 chmod -R 777：会把所有用户和进程都变成可写，等于用安全风险掩盖属主错误。
整站 chown 给 www-data：在共享主机、面板隔离用户或 Git 部署环境中，可能破坏后续发布和隔离机制。
只清缓存：缓存不会修复写权限、磁盘或 SELinux。
反复点击更新：会留下更多临时目录，甚至把站点卡在维护模式。
没看磁盘就改权限：inode 用尽时，权限再宽也创建不了新目录。

如果你希望把 WordPress 部署、备份、更新和服务器维护集中在一套流程中，可以先查看 SHOPAGG 视频课程，按站点管理的完整顺序操作，而不是遇到一个报错就临时搜索一条命令。

作者：庄朋龙，SHOPAGG 官方博客编辑。本文命令以常见 Linux 服务器为例；涉及生产站点权限和属主调整时，请先确认实际运行用户并保留可恢复备份。资料核对日期：2026年10月3日。