在 Synology NAS 上部署 WordPress 时，系统常常弹出“请输入 FTP 账户和密码”的对话框，这背后并非偶然，而是文件系统权限与执行用户不匹配的直接表现。NAS 的 Web Station 通常以 http（或 www-data）用户运行 PHP，而 WordPress 在执行升级、插件安装等写操作时，会尝试以 nobody 身份写入核心目录。两者权限差距导致写入失败，WordPress 便退回到最保守的 FTP 方式以获取写权限。
Synology 的文件共享服务（DSM）默认把共享文件夹的所有者设为 admin，而访问 Web 服务的进程则使用 http 用户。若未手动修改文件夹 ACL，http 只能读取，无法创建或覆盖文件。WordPress 在调用 wp-admin/upgrade.php 或插件安装脚本时，检测到写入受阻，便自动切换到 ftp、ssh2 或 ssh 方式，要求提供外部传输凭证。
wp-config.php 中加入 define('FS_METHOD', 'direct');，强制所有文件操作走 PHP 本身的读写权限。wp-content 子目录设置适当的 POSIX 权限：755（rwxr-xr-x），文件 644（rw-r--r--），wp-config.php 进一步收紧至 600。http（或对应的 www-data）用户加入“读写”组，确保 PHP 进程拥有实际的写入权。zip 解压插件，务必在 Web Station‑>PHP 设置中勾选 zip 扩展，否则 WordPress 会回退到 FTP。很多用户误以为只要把文件夹所有者改为 http 就能解决问题，实际上 DSM 的 ACL 仍可能限制写入。检查时，可在终端执行 ls -l /volume1/web/wordpress，确认属于 http 并且组权限为 rw。如果发现 nobody 仍是执行用户，说明 PHP-FPM 池的 user 配置未同步，需要在 /etc/php-fpm.d/www.conf 中手动指定为 http，随后重启服务。
“FTP 只是一种后备手段，真正的解决之道在于让 Web 进程本身拥有写权限。”
把权限纠正到位后，WordPress 的自动升级、插件安装便不再弹出密码框，整个站点的维护流程也随之顺畅。只要记得在每次 DSM 系统更新后重新核对 http 的 ACL，问题基本可以被彻底根除。
参与讨论
我试过把文件夹属主改成http，结果DSM ACL还拦着，折腾半天才发现要改php-fpm池。
这个方法靠谱吗？把wp-config改成direct会有安全风险吗，谁解释下。
前几天刚搞完这个，确实折腾了好久，最后在DSM里把http加进读写组才行。
权限这事儿真坑，照着改了FS_METHOD就不问了，省心多了。
感觉说明清楚了，照着改权限和php配置基本能稳定运行。
为什么zip扩展不勾选就回退FTP？这细节之前真没注意，学习了。
要是有人怕出错，先在测试目录练手，别一上来就改生产站权限，风险太大。
我之前也踩过这坑，php-fpm的user没对上导致nobody写不进去，改完重启就正常了。
又是权限问题，Synology这类NAS就爱搞一套自己的ACL，折腾人的节奏。
能不能写个一步步的脚本自动修复这些权限，手动改太繁琐了，谁来做个工具？
按作者说法改了应该不会再弹FTP，但每次DSM更新后记得复查ACL，别懈怠了。