vsftpd 2.3.5+ 版本强制要求 chroot 根目录对用户不可写，否则报 500 OOPS 错误；根本原因是防止通过符号链接等手段逃逸，解决方案包括：设根目录为 755（root 拥有）并在其下建可写子目录、禁用 allow_writeable_chroot（仅测试可用）、或用 user_sub_token 动态指定 root 路径。
vsftpd 启用 chroot 后报 500 OOPS: refusing to run with writable root inside chroot，根本原因是 vsftpd 2.3.5+ 版本强制要求 chroot 目录不可写（出于安全考虑），而用户常把 /home/username 设为可写并直接 chroot 进去 —— 这会触发拒绝启动。
为什么不能让 chroot root 可写
vsftpd 认为：如果用户被限制在 /home/username，而该目录本身对用户可写（比如权限是 755 或更宽松、且属主是该用户），攻击者可能通过符号链接、重命名等手段逃逸或覆盖关键文件。因此新版本默认拒绝这种配置。
常见错误现象：
– 用户登录时立即返回 500 OOPS: refusing to run with writable root inside chroot
– vsftpd 进程不崩溃，但对应用户连接直接被拒
– chroot_local_user=YES + local_root 指向用户家目录时必现
三种合规解法及适用场景
必须满足「chroot 目录对用户不可写」，但又要让用户能上传文件 —— 关键在于把「可写子目录」和「chroot 根目录」分开：
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
方案一（推荐）：设 chroot 目录为只读，再挂载或创建可写子目录
– 把用户家目录权限改为755（属主可读可执行，不可写）
– 在其下新建upload目录，设为775，属主为用户、属组为 ftp 或同组
– 确保vsftpd.conf中有allow_writeable_chroot=NO（默认值，不建议改） -
方案二：用
allow_writeable_chroot=YES（仅限测试环境）
– 在/etc/vsftpd.conf中显式添加allow_writeable_chroot=YES
– ⚠️ 该选项自 vsftpd 3.0.0 起被标记为不安全，生产环境禁用
– 不解决根本风险，只是绕过检查 -
方案三：换用
user_sub_token+ 动态 chroot 路径
– 设置chroot_local_user=YES
– 设置local_root=/var/ftp/users/<code>%u
– 创建/var/ftp/users/username目录，权限设为755，属主为 root
– 再在其中建upload目录，属主为 username，权限775
权限与配置联动要点
无论选哪种方案，以下操作缺一不可：
- chroot 目录（即
local_root指向的路径）必须由root拥有，且用户对该目录**无写权限**（chmod 755 /path是安全底线） - 用户真实可写目录必须是 chroot 目录的**子目录**，且属主为该用户（如
chown username:ftp /path/upload） - 确保
vsftpd.conf中未启用write_enable=NO；上传需write_enable=YES+anon_upload_enable/anon_mkdir_write_enable等按需开启 - SELinux 开启时，还需确认上下文：用
ls -Z /path检查，必要时执行chcon -t public_content_rw_t /path/upload并setsebool -P allow_ftpd_anon_write=1
最易忽略的一点：改完权限后忘记重启服务，或改了配置但没 reload —— 执行 systemctl restart vsftpd 或 service vsftpd reload 才生效。另外，用户家目录若由 adduser 自动创建，默认是 700，看似安全，但 vsftpd 会因「属主可写」而拒绝，必须手动降权到 755 并移交 root 拥有。
