What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The error means the directory vsftpd uses as the chroot jail is writable by the FTP user. The secure fix is to make that jail root owned by root and non-writable, then create a writable child directory for uploads. Keep allow_writeable_chroot=NO (the default) unless a legacy application genuinely requires the jail root itself to be writable.
What the error means
When vsftpd puts a local user in a chroot() jail, the user sees the jail directory as the filesystem root. vsftpd rejects the setup when that root directory can be modified by the same user. The refusal commonly appears as:
500 OOPS: vsftpd: refusing to run with writable root inside chroot()
The configuration reference describes allow_writeable_chroot as the switch that permits chrooting a user to a directory writable by that user. Its default is NO. The security concern is that a user who can write the jail root could create an etc directory and influence which configuration files are loaded. The vsftpd FAQ therefore says the FTP home directory should not be owned by the FTP user and should not be writable by that user.
This defensive check is associated with vsftpd 2.3.5 and later guidance. A configuration that worked with an older package can begin failing after an operating-system or appliance upgrade.
Identify the directory vsftpd is protecting
Do not change permissions until you know which directory is the actual jail root. Depending on the installation, it may be the user’s home directory, the value of local_root, a per-user setting, or an equivalent path managed by the platform.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Find the account’s home directory:
getent passwd ftpuser. Replaceftpuserwith the login that receives the error. The final field in the returned line is the home path. - Inspect the main configuration and any included or per-user files for
local_root:sudo grep -R --line-number --fixed-strings 'local_root' /etc/vsftpd.conf /etc/vsftpd* 2>/dev/null. Distribution layouts differ, so also check the directory configured for per-user files if your installation uses one. - Check the candidate directory and every parent component:
namei -l /srv/ftp/userandstat -c '%U:%G %A %n' /srv/ftp/user. Replace the example path with the path you found. - Resolve indirection before changing anything:
readlink -f /srv/ftp/user. A symlink, bind mount, or appliance-generated path can mean that the directory you inspected is not the one whose permissions are being evaluated.
The relevant test is whether the authenticated FTP user can write the directory that becomes the jail root. A root-owned directory can still be unsafe if its group or other permission bits grant write access, so check all three permission classes.
The secure directory layout
Keep the jail boundary immutable and put upload data below it. ArchWiki’s example uses /srv/ftp/user as the non-writable root and /srv/ftp/user/upload as the writable child.
| Path | Suggested owner | Mode | Purpose |
|---|---|---|---|
/srv/ftp/user |
root:root |
550 |
Chroot root; readable and traversable, but not writable by the FTP account |
/srv/ftp/user/upload |
The FTP account and its group | 750 |
Writable upload area beneath the jail |
Mode 550 gives the owner and group read and search permission without write permission; mode 750 gives the upload owner full access and the group read and search access. If your workflow needs a different group arrangement, change the group deliberately rather than making the whole jail writable. The exact owner and group must match the account that is supposed to create files.
Step-by-step: make the jail root safe and keep uploads working
1. Back up the current state
Record the existing ownership and modes before editing them:
Recommended Free Tools
sudo stat -c '%U:%G %A %n' /srv/ftp/user /srv/ftp/user/upload 2>/dev/null
Use your real jail path. This gives you a rollback reference and helps identify an unexpected group-write bit.
2. Remove write access from the jail root
For the example path, run:
sudo chown root:root /srv/ftp/user
sudo chmod 550 /srv/ftp/user
The FAQ’s equivalent example is chown root ~ftp followed by chmod -w ~ftp. Dell documents the same principle with chmod a-w /home/user. Use the path that is actually configured as the jail root, not necessarily the account’s ordinary home directory.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchDo not use chmod -R on the entire tree as a first response. Existing files may need different modes, and recursive changes can remove permissions required by applications or administrators.
3. Create a writable child directory
Create the upload directory below the protected root and assign it to the FTP account. In this example, substitute the real account and group for ftpuser:ftpgroup:
sudo mkdir -p /srv/ftp/user/upload
sudo chown ftpuser:ftpgroup /srv/ftp/user/upload
sudo chmod 750 /srv/ftp/user/upload
If the directory already contains files, inspect their ownership separately. The user needs write and search permission on the upload directory itself; the parent only needs to permit traversal. The FTP client should now upload to the child path, which appears inside the jail as /upload.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors4. Point vsftpd at the protected root
If the configured root is wrong, set local_root=/srv/ftp/user in the appropriate vsftpd configuration scope. A global setting affects every applicable local user; a per-user file is safer when accounts need different jails. Keep the root path non-writable even when users have separate upload directories.
5. Restart or reload the service
Use the service mechanism supplied by your Linux distribution:
sudo systemctl restart vsftpd
sudo systemctl status vsftpd --no-pager
If your package supports a configuration reload and you prefer not to terminate existing sessions, use sudo systemctl reload vsftpd. A restart is the clearer diagnostic choice after changing ownership or a startup setting. Check the service status and logs supplied by your distribution if it does not return to an active state.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →6. Test both sides of the permission boundary
- Log in with the affected FTP account. The session should start without the 500 error.
- List the jail root and confirm that the client can enter
/upload. - Upload a small test file into
/upload. It should be created there, not in the jail root. - Attempting to create a file directly in the jail root should fail. That failure is expected and confirms that the boundary is working.
- Verify the resulting file on the server with
stat, then remove the test file if it is no longer needed.
Why a writable child does not trigger the error
vsftpd checks the directory that represents the user’s chroot root, not every directory beneath it. A child upload directory can be writable because it is not the directory used as the new filesystem root. The arrangement separates two duties:
- The root-owned parent prevents the user from changing the jail’s top-level contents or creating an
etcdirectory there. - The child directory supplies the write access required by uploads.
- Administrators can add additional read-only directories or separate upload locations without weakening the chroot boundary.
If an application insists on writing directly to the user’s apparent root, move its working directory to a named child where possible. Changing the application path is safer than relaxing vsftpd’s check.
Workaround: allow a writable chroot root
When a legacy workflow genuinely requires the chroot root itself to be writable, add:
allow_writeable_chroot=YES
The option can be placed in the global configuration or in a per-user configuration file, depending on how your installation is organized. A per-user setting limits the exception to accounts that need it; a global setting removes the protection for every affected user.
The configuration reference warns that enabling this option can create security problems. Dell presents it as the second remediation option, after making the root non-writable. Before using it, document why the application cannot use a child directory and reduce other exposure as far as the environment permits:
- Use a per-user configuration rather than a global override when only one account needs it.
- Give the account access only to the files and services required for its job.
- Review group membership and parent-directory permissions for unintended write access.
- Monitor the account and keep the FTP service and operating system patched.
- Retest after every configuration or package upgrade because the exception changes a deliberate security boundary.
Do not combine the override with broad recursive write permissions unless the application has an explicit, documented need. If the application can be changed, a writable child remains the preferred design.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choosing between the two remediations
| Decision axis | Protected root plus writable child | allow_writeable_chroot=YES |
|---|---|---|
| Security boundary | Strongest: the jail root cannot be modified by the FTP user | Weaker: the user can alter the directory used as the jail root |
| Application compatibility | Works when software can write to a subdirectory | May be required by legacy software that writes at the apparent root |
| Operational durability | Filesystem permissions normally survive service restarts; managed platforms still need upgrade checks | The setting can be lost or changed by package and platform configuration management |
| Scope | Applies naturally per jail and per upload directory | Can be global or per user; per-user is less expansive |
Use the protected-root layout unless a tested compatibility requirement rules it out. Treat the override as an exception with an owner, a reason, and a review date.
Troubleshooting after the change
The same 500 error still appears
- You changed the wrong directory. Recheck
local_root, the account’s home path, and any per-user configuration. Usenamei -landreadlink -fon the exact path. - A group or other write bit remains. Run
stat -c '%U:%G %A %n' /path/to/jailand remove write access from every class.chmod 550 /path/to/jailis an explicit example when that mode fits your access model. - The daemon was not reloaded. Restart or reload vsftpd through the distribution’s service manager and check its status.
- A per-user file overrides the global value. Search all included configuration locations for
allow_writeable_chrootandlocal_root. Configuration precedence is installation-specific, so verify the effective file used by the account. - The path is generated by a managed platform. An appliance may recreate the directory or configuration after a service operation. Apply the change through its supported management mechanism.
Login succeeds but uploads fail
- Confirm that the client is entering the writable child, such as
/upload, rather than attempting to write to the jail root. - Check the child’s owner, group, and mode with
stat. The authenticated account needs write and search permission there. - Check every parent directory for search permission. A writable child cannot be reached through a parent that denies traversal.
- Look for a disk-full condition, read-only filesystem, quota, or a platform access-control policy if ordinary Unix ownership and modes are correct.
Uploads go to an unexpected location
Inside a chroot, the user sees the jail root as /, so a client path such as /upload maps to the host path /srv/ftp/user/upload in the example. Verify local_root and the account’s home directory, then inspect the resulting file on the host rather than relying only on the client’s display.
The fix disappears after an upgrade
Dell reports the same failure after OneFS upgrades moved systems from older to newer vsftpd packages and warns that direct edits to an OneFS configuration template may not persist. On a managed appliance, use the vendor-supported configuration workflow and record the intended ownership, modes, and vsftpd options so they can be reapplied after an upgrade. On a conventional Linux server, check package-managed configuration files and service overrides after upgrading.
Version and upgrade considerations
ArchWiki dates the non-writable-jail requirement to vsftpd 2.3.5. The practical implication is that upgrading from an older package can expose a permission layout that was previously accepted. Do not interpret the new refusal as proof that uploads must be disabled: move writes into a child directory first. If compatibility testing proves that impossible, evaluate the narrowly scoped override and document the risk.
Quick Recap
Final checklist
- Identify the effective chroot root for the affected account.
- Make that directory owned by root and remove write permission for the FTP user, group, and others.
- Create a dedicated writable child such as
upload. - Assign the child to the account that must upload and choose the least-permissive workable mode.
- Restart or reload vsftpd and verify service status.
- Test login, child-directory upload, and expected denial at the jail root.
- Use
allow_writeable_chroot=YESonly for a documented compatibility requirement, preferably in a per-user configuration. - Recheck permissions and configuration after package or managed-platform upgrades.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
