FTP 421 Home Directory Not Available — Aborting: Causes and Fixes

What does FTP 421 Home Directory Not Available — Aborting mean, and when does it occur?

The message 421 Home directory not available - aborting means that the FTP server could not provide the user with the assigned home directory. You should diagnose the complete server response and the point where it appears in the FTP session, not the numeric 421 code by itself.

A failed connection may look like this:

Status: Connecting to ftp.example.com...
Response: 220 FTP server ready
Command: USER ftpuser
Response: 331 Password required
Command: PASS ********
Response: 421 Home directory not available - aborting

This log already tells us that the server is reachable, the TCP connection was established, the FTP service responds, and the USER command was processed. The error appears later, around the point where the server must prepare the user's environment and change into the assigned directory.

This is not universal proof that the password is correct: the exact sequence depends on the FTP server and authentication scheme. Still, such a log points much more strongly to the home directory, user mapping, or filesystem access than to a firewall or network connectivity problem.

How is FTP 421 Home Directory Not Available different from 530 Login Incorrect?

530 Login incorrect or a similar response usually sends the investigation toward the username, password, FTP login permissions, and authentication method. With 421 Home directory not available, the server explicitly reports a problem with the user's filesystem environment.

Changing the password may therefore have no effect at all. If the FTP account is configured to use /home/olduser/site but the directory was moved to /home/newuser/site during migration, a new password will not fix the old path.

How is this different from FTP 421 Too Many Connections?

FTP servers use the 421 code in different situations. A Too many connections response points toward connection limits, stale sessions, or per-IP restrictions. Home directory not available points to the FTP user's filesystem environment.

So the first guide you find for “FTP 421” may be completely unrelated to your problem. The full server response matters more than the numeric code.

How can you find where the FTP login fails in 5 minutes?

The first useful test is to determine the scope of the problem. If one FTP user gets 421 while another account on the same server logs in normally, shared storage and the FTP service move down the list of suspects. Start with the affected account, its home directory, permissions, and isolation.

If all FTP users for one website stop working, look for a common element: the website directory, file owner, FTP account settings, or a changed path. If accounts across the whole server receive 421, it makes more sense to start with the shared filesystem, mounts, and server configuration.

Minimal diagnostic sequence

1. Save the complete log of the failed FTP connection.
2. Test another FTP account on the same server.
3. Determine the home directory assigned to the affected user.
4. Confirm that this exact path exists.
5. Check access through the entire directory chain, not only the final directory.
6. Check FTP User Isolation, chroot, or virtual-user mapping.
7. If many accounts are affected, check the filesystem and storage.
8. Compare your hypothesis with the server-side FTP log.

A useful rule is simple: if a neighboring FTP account works, do not begin with the service or disk. If dozens of users fail immediately after a reboot, checking each account individually is usually a waste of time.

How do you check whether the Home Directory exists and whether FTP uses the correct path?

You need to identify the home directory actually assigned to the affected FTP user. The directory an administrator considers the user's home, the website DocumentRoot, and the FTP entry point can be three different paths.

Checking the FTP home directory on Linux

If FTP uses a regular Linux system user, start with the NSS database:

getent passwd username

The result may look like this:

username:x:1003:1003::/home/username:/bin/bash

Here, /home/username is the system home directory. Check the path itself:

ls -ld /home/username
stat /home/username
realpath /home/username

ls -ld shows the owner and basic permissions, stat provides metadata, and realpath helps detect a symbolic link and resolve its final target.

If realpath unexpectedly fails even though the link itself exists, check the link target. The FTP account may still point to a directory that was moved or deleted while the symbolic link remained.

If getent passwd returns nothing, that does not mean the FTP account does not exist. Pure-FTPd, ProFTPD, vsftpd, and hosting panels may use virtual users or a separate backend. In such setups, the home directory does not have to come from the system user database.

Do not confuse the website DocumentRoot with the FTP home

A working website proves nothing about the FTP path. Nginx or Apache may serve files from /var/www/example.com/public while a separate FTP account still points to /home/customer/example.com.

This is especially common after migration: the website has already been switched to the new DocumentRoot while the additional FTP account still uses its old mapping.

Compare these two values:

FTP user: ftp@example.com
Configured home: /home/customer/example.com/public_html

and:

realpath /home/customer/example.com/public_html

If the configured FTP home does not exist or resolves to the wrong location, leave the permissions on the neighboring working directory alone. Fix the path first.

How to check the physical path and FTP User Isolation in IIS

On IIS, checking the folder in File Explorer is not enough. You need to match the FTP site's physical path, the selected FTP User Isolation mode, and the directory IIS expects for the specific login.

1. Open IIS Manager and select the affected FTP site.
2. Open Basic Settings and note the physical path.
3. Return to the FTP site and open FTP User Isolation.
4. Check which isolation mode is selected.
5. Match that mode to the directory the specific FTP user should enter.
6. Only then check the NTFS ACL of the target folder.

The chain is short: FTP login → User Isolation mode → expected user directory → NTFS permissions. If IIS already resolves the login to the wrong directory, changing ACLs on an existing folder will not help.

You can inspect basic directory ACLs from the Windows command line:

icacls "D:\sites\example"

For a more detailed PowerShell view:

Get-Acl "D:\sites\example" | Format-List

The goal is not to assign the broadest possible permissions. You need to confirm that the account or security context IIS uses to access the directory actually has the required permissions.

Additional FTP accounts in hosting control panels

An additional FTP user's home directory often sits inside the primary account's directory tree, for example:

/home/customer/example.com/uploads

If uploads was deleted, the FTP account may still exist while its root directory is gone. Another common case is a migrated website that already works from the new directory while the additional FTP user's directory mapping still points to the old path.

The panel brand is not the key issue. Find the directory assigned to the specific FTP account and compare it with the real path on the server.

Why does FTP return 421 when the home directory physically exists?

A directory can exist and be accessible to root while remaining inaccessible to the FTP user. On Linux, access to /home/customer/site/public_html depends not only on the permissions of public_html: the user must also be able to traverse every component in the path.

The folder exists. Access can still fail.

Check permissions on every parent directory in Linux

This command:

ls -ld /home/customer/site/public_html

shows only the final directory. For a 421 error, it is more useful to check the entire chain:

namei -l /home/customer/site/public_html

The output may look like this:

f: /home/customer/site/public_html
drwxr-xr-x root     root     /
drwxr-xr-x root     root     home
drwx------ customer customer customer
drwxr-x--- customer web      site
drwxr-xr-x customer web      public_html

If access already breaks at /home/customer, the permissions of public_html are not the problem yet. For directories, the execute bit controls traversal and access to known entries inside the directory. Seeing 755 on the final folder does not reveal a restriction higher in the tree.

Also check the final directory and the user's groups:

stat -c '%U:%G %a %n' /home/customer/site/public_html
id username

If FTP really runs under a regular system user, test traversal as that user:

sudo -u username test -x /home/customer/site/public_html && echo OK

There is an important limitation: a successful test -x confirms traversal, but it does not prove full FTP access. Reading directory entries requires appropriate read permission, while creating or deleting entries requires write permission together with traversal.

After test -x, it is therefore useful to test actual directory reading as the same user:

sudo -u username ls -la /home/customer/site/public_html

This test applies only when the FTP user corresponds to a system account or when its real filesystem context is known. For a virtual user, test the mapped account, chroot, and FTP daemon configuration instead.

Ownership, UID/GID, and ACLs

After migration, owner names may look familiar, but the filesystem works with numeric identifiers. Compare:

ls -ln /home/customer
id username

The files may have arrived with UID 1005 while the new username received UID 1017. Those are different owners even if the administrator only looked at the account name in the control panel.

If the standard mode bits look correct, inspect ACLs:

getfacl /home/customer/site/public_html

An ACL can extend access or restrict it through its mask. The task is to find the specific point in the directory chain where the real FTP user loses access, not to reset permissions recursively across the whole tree.

NTFS permissions and IIS FTP Authorization Rules

In IIS, FTP authorization and filesystem permissions are separate layers. FTP Authorization Rules determine who may access the FTP site, while NTFS ACLs control filesystem operations.

A user may be allowed by IIS and still have no access to the target directory. Compare:

• the FTP site's physical path;
• FTP Authorization Rules;
• FTP User Isolation;
• NTFS Security on the target directory;
• the security context IIS uses to access the files.

How can FTP User Isolation, chroot, and virtual users cause Home Directory Not Available?

If the directory exists, owners match, and the standard permissions look correct, check the filesystem entry point the FTP server builds for the user. With FTP User Isolation, chroot, and virtual users, the system home and the effective FTP root may be different.

IIS FTP User Isolation

IIS FTP can isolate users so that each sees only the space assigned to that account. In this mode, the server does not have to send the FTP login directly to the site's physical path: the final directory depends on the selected User Isolation scheme.

A typical situation looks like this: the administrator checks D:\sites\example, sees that the directory exists and has reasonable NTFS ACLs, but IIS is trying to open a different directory for the current user. The existing folder is simply not the home IIS expects.

Check in this order: the FTP site's physical path, the selected User Isolation mode, the directory for the specific username, and then the NTFS ACL. If the path already does not match, leave permissions alone for now.

What to check with chroot on Linux FTP

In a chroot setup, the FTP user works inside a restricted root. A path that exists for root in the normal filesystem may be outside the filesystem view available to the FTP session.

Check symbolic links separately. For example:

/home/ftpuser/files -> /srv/storage/customer-files

The link may work from a normal shell while its target is unavailable inside the isolated FTP environment. Resolve the target with realpath, then compare it with the chroot boundaries.

Configuration parameters differ between FTP daemons. With vsftpd, troubleshooting often includes checking chroot settings and local_root if it is used. In ProFTPD, directives such as DefaultRoot and DefaultChdir may play a similar role. This is not a universal configuration recipe: control panels and virtual-user backends may override the simple system-user model.

If the server log shows that the daemon cannot chdir into a directory that exists outside the FTP session, compare the normal filesystem path with the root actually visible from inside FTP.

How to diagnose a virtual FTP user

An FTP login does not have to match a Linux username. Therefore:

getent passwd ftp-login

may return nothing even though the FTP account exists and the server accepts the login. In that case, break the chain down differently:

1. The FTP login entered by the user.
2. The record for that login in the FTP backend or control panel.
3. The system or service account used to access files.
4. The home or local root assigned to the virtual user.
5. The final directory after chroot and mapping are applied.

If one FTP account works while another account using the same mapped system user gets 421, the shared daemon and storage are less suspicious. Compare the home settings of the two virtual users.

The value you need is the directory the FTP server sees as root/home after user mapping and isolation have been applied. That is the path you must compare with the filesystem.

Why does FTP 421 appear after a website migration, backup restore, or account change?

If FTP worked before a migration, backup restore, or account rename, first look for a mismatch between the FTP account, home path, and file ownership. The website files may have been restored successfully while the FTP service metadata was not.

FTP still uses the old path

Before migration, the directory may have been here:

/home/olduser/example.com

and after migration:

/home/newuser/example.com

The website already works because Nginx or Apache points to the new DocumentRoot. The additional FTP account, however, may still reference /home/olduser/example.com. The result is a characteristic pattern: the website works, SSH works, but one FTP login fails with 421.

Compare the path in the FTP account settings with the actual file location and resolve it with realpath.

UID and GID changed

After restoring the files, compare the numeric identifiers:

id newuser
ls -ln /home/newuser
stat /home/newuser/example.com

If the files still belong to the old UID while the new user received another numeric ID, the account name alone does not solve the problem. Correct the ownership of the affected tree according to the hosting setup instead of granting write access to everyone.

The files were restored, but FTP metadata was not

A backup of a website directory and a full hosting-account backup are different things. An archive may contain PHP files, images, and CMS configuration but omit additional FTP users, their home paths, and panel mappings.

After a manual migration, recreating an additional FTP account can sometimes be the right fix. But only do this after confirming that its metadata no longer matches the new structure. If the real problem is a missing mount or blocked parent directory, creating a new FTP login will not solve anything.

An old symlink or bind mount remains

Part of the directory tree may still point to the old layout:

realpath /path/to/ftp/home
findmnt -T /path/to/ftp/home

If realpath resolves to another disk or findmnt shows an unexpected filesystem, the problem is already below the FTP account layer.

When should you check the disk, mount, or network storage instead of FTP settings?

Storage should move higher on the list of suspects if several FTP accounts stop working at once, their home directories are located on the same volume, or the problem appeared after a reboot. In that case, dozens of apparently broken users may have one shared cause: a missing filesystem.

The mount-point directory exists, but the filesystem is not mounted

A separate /home filesystem is a good example. The /home directory itself still exists in the root filesystem even if the expected partition was not mounted. So ls -ld /home alone proves nothing.

To check the mount point itself:

findmnt /home

If the FTP home is deeper in the tree and is not itself a mount point, identify the filesystem serving that path:

findmnt -T /home/customer/example.com
df -h /home/customer/example.com

findmnt -T shows which filesystem serves the specified path, while df -h is limited to the relevant home instead of listing every disk on the server.

The expected result is the familiar source and mount point. If the home directory suddenly resolves to the root filesystem after a reboot instead of the dedicated disk, checking chmod for every FTP user is unnecessary. The fault is lower in the stack.

Network shares in Windows and IIS

If the FTP site's physical path points to a network resource, check both the share itself and the IIS security context. A network path may open in an administrator's interactive session while remaining inaccessible to the service.

• check the UNC path;
• verify that the resource is reachable from the FTP server;
• check share permissions;
• check NTFS ACLs on the remote side;
• check the credentials IIS uses to access the resource.

A full disk or read-only filesystem does not automatically explain 421

A nearly full disk should be fixed, but it does not by itself prove the cause of Home directory not available. If an existing directory is readable, the FTP server may still be able to open it even when there is no space for a new upload.

The same applies to a read-only filesystem: being unable to write a file and being unable to enter a directory are different symptoms. Connect that state to this specific 421 error only when the server log confirms a problem opening the home directory.

But if all FTP homes on one volume fail at once, the directory contents look different after a reboot, and findmnt -T reports an unexpected filesystem, the problem is no longer in the individual FTP accounts.

Which FTP logs and server-side checks can reveal the exact cause of 421?

When the path and permissions look correct, move to the server-side log. It often turns a generic 421 response into a specific cause: a missing directory, Permission denied, a chdir failure, a chroot problem, or incorrect user mapping.

How to identify the FTP daemon running on Linux

If the server was configured a long time ago or FTP was installed by a hosting control panel, you may not know the service name. First check which process listens on the standard FTP port:

ss -ltnp | grep ':21 '

Then check for common running FTP services:

systemctl --type=service --state=running | grep -Ei 'vsftpd|proftpd|pure-ftpd'

This is not universal for every configuration: FTP may use a non-standard port or another service manager. But on a typical VPS, this test quickly tells you which daemon to look for in the logs.

For the discovered service:

systemctl status <ftp-service>
journalctl -u <ftp-service>

Match the client log to the server log by time

Do not read the entire log from top to bottom. Make one test connection, note the time, username, and client IP, then find the corresponding records on the server. This is often the fastest way to separate two externally similar cases: “the path does not exist” and “the path exists but access is denied.”

A server-side log fragment may look like this:

ftpuser: cannot change directory to /home/customer/example.com: Permission denied

The exact wording depends on the FTP daemon. The meaning matters more: the server has already named both the operation and the directory. After a message like this, do not reinstall FTP — check traversal, ownership, and ACLs on that path.

Another type of message:

ftpuser: cannot change directory to /home/olduser/example.com: No such file or directory

This is a different branch: FTP is pointing to a missing path. Check the account home, migration changes, and symbolic links first.

• No such file or directory — home path, symlink, mount;
• Permission denied — traversal, owner, group, ACL;
• cannot chdir — path, permissions, or isolation;
• chroot error — effective FTP root and daemon requirements;
• user mapping error — FTP backend or control panel;
• authentication failure — username, password, and authentication scheme.

What to check in IIS FTP

In IIS, match the failed login time with FTP logs and Windows events if the service recorded an additional error in Event Viewer. Then check the configuration of that same FTP site:

• Basic Settings and the physical path;
• Authentication;
• FTP Authorization Rules;
• FTP User Isolation;
• NTFS permissions;
• remote resource access if a network share is used.

If one user can log in to the same FTP site while another receives 421, comparing their isolation/home settings and ACLs is usually more useful than rechecking the entire IIS service.

Why the client log is still useful

The server log shows the internal cause, while the client log records the external behavior. Save the command/response sequence before the fix, then repeat the connection afterward.

Before:

USER ftpuser
331 Password required
PASS ********
421 Home directory not available - aborting

After the cause is fixed, the FTP session should continue and return a directory listing. A single Connected status line is not enough.

In what order should you fix FTP 421 Home Directory Not Available and verify the result?

The correct fix depends on what the diagnostics already confirmed. There is no need to repeat every command again: by this point you should have a specific fault — the wrong home, a blocked parent directory, incorrect mapping, an unavailable mount, or an isolation problem.

Recreating an FTP account is justified when its metadata was actually damaged after migration or a control-panel failure, or when it still points to an obsolete path and its settings can be recreated safely. If the server log shows Permission denied on an existing home or the storage is not mounted, creating a new FTP login will only hide the real cause.

How to verify the result after the fix

A successful login does not prove that FTP is configured correctly. Check not only that 421 disappeared, but also that normal operations work:

• the user enters the expected home directory;
• the directory listing opens;
• the user can enter a subdirectory;
• a file downloads completely without a Transferred a partial file error;
• a test file can be uploaded if the account is supposed to have write access;
• the user cannot see directories outside the assigned FTP root.

The final check matters especially after changing permissions or isolation. If 421 disappears but the FTP user can now see neighboring websites or other users' home directories, the problem has not been fixed — it has merely changed form.