在 Synology NAS 上部署 WordPress 时,管理员经常会在执行「升级核心」或「安装插件」的操作后,弹出要求输入 FTP 账户和密码的对话框。表面上看,这似乎是网络环境的限制,实则是文件系统权限与 PHP 运行身份之间的冲突导致 WordPress 只能回退到 FTP 方式进行写入。
Synology 的 Web Station 默认使用 http(或 www-data)用户运行 PHP,而 NAS 的共享文件夹则以 nobody 或 users 组提供访问。WordPress 在尝试写入 wp‑content、wp‑admin 等目录时,实际进程的 UID 与文件的所有者不匹配,导致系统返回「权限不足」错误。WordPress 在检测到写入失败后,会自动切换到 FTP(或 SFTP)模式,要求管理员提供凭证以完成同样的操作。
wp-config.php 设置为 600 并不影响 FTP 提示,但若文件拥有者仍是 nobody,PHP 仍无法直接写入。下面列出一套在 Synology 环境下的「对症下药」步骤,确保 WordPress 能够直接使用 PHP 进程完成文件写入:
Web Station → PHP Settings 中勾选 zip 扩展,保存并重启 PHP。chown -R http:http /volume1/web/wordpress(或对应共享路径),让所有 WordPress 文件归属 http 用户。775,文件默认 664,wp-config.php 单独设为 600。wp-config.php 末尾加入 define('FS_METHOD', 'direct');,强制 WordPress 采用直接写入模式。完成上述操作后,重新登录 WordPress 后台,尝试一次插件更新或核心升级,系统应不再弹出 FTP 提示,更新过程会在几秒钟内完成。
Synology 官方在套件中心提供的 WordPress 包,默认关闭了直接写入权限,意在防止普通用户误操作导致系统文件被篡改。于是系统把升级路径封装在自家的套件更新机制里,而非开放给 WordPress 自身的自动更新功能。这也是为什么即使在后台看到「有新版本」的提示,实际只能等待 Synology 推送新的套件版本。
参与讨论
这个http用户在哪看的?SSH里查吗?
前几天刚搞完这个,确实折腾了好久
define那行加了之后要清缓存不?
群晖这权限设计真的反人类🤔
试了chown但volume1路径不对咋办?
为啥我改了权限还是弹FTP啊?
zip扩展开了还是不行,无语
感觉还行,按步骤弄好了
wp-config.php设600后后台打不开了…
是不是必须用套件中心装的WordPress才行?
我之前也踩过这坑,最后重装解决的
hhh终于不用每次输FTP密码了
关键目录775会不会有安全风险啊?
Synology为啥非要把简单事搞复杂
有人试过Docker跑WordPress没这问题吗?