Fix vsftpd “530 Login incorrect” Errors on Linux

A vsftpd 530 Login incorrect response does not prove that the password is wrong. It means authentication or an account-access policy rejected the session. For a local Linux account, verify local_enable=YES, the PAM service selected by pam_service_name, the account’s lock, expiry and shell state, and any user-list rules before changing credentials again. Use the logs while reproducing one login; they identify which gate failed.

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

What the 530 response actually tells you

FTP status 530 is a deliberately broad failure response. vsftpd can send it after a password check fails, but it can also use the same response when a PAM rule denies the account, the account is locked or expired, the login shell is not permitted, or a user-list policy blocks the name before password validation. FileZilla and other clients usually display only the final 530 text, so repeatedly typing the same password rarely supplies useful evidence.

#	Preview	Product	Price
1		Mastering Linux Administration: Take your sysadmin skills to the next level by configuring and...	$49.99	Buy on Amazon
2		UNIX and Linux System Administration Handbook		Buy on Amazon
3		How Linux Works, 3rd Edition: What Every Superuser Should Know	$46.59	Buy on Amazon
4		Linux Administration: The Linux Operating System and Command Line Guide for Linux Administrators	$2.99	Buy on Amazon
5		The Linux Command Line, 3rd Edition: A Complete Introduction	$27.94	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

Treat the response as an authentication-or-policy checkpoint. First establish which configuration the daemon loaded, then inspect PAM and the account, and only after those gates pass investigate filesystem isolation. A chroot problem normally produces a separate 500 OOPS message rather than a password error.

Use this order for a first repair attempt

1. Confirm the running service and configuration path. Run systemctl status vsftpd. Check the unit and its launch arguments with systemctl cat vsftpd, then verify that the file being read is the one you edited, commonly /etc/vsftpd.conf (some distributions use a different path).
2. Enable the authentication source you intend to use. For ordinary Linux users from /etc/passwd or a directory service, the configuration must contain local_enable=YES. The Debian vsftpd manual specifies that this is required for any non-anonymous login, including virtual users. Set write_enable=YES only when the account must upload, delete or otherwise modify files; it is not needed merely to authenticate.
3. Watch the daemon and authentication logs during one test. In one terminal run journalctl -u vsftpd -f. In another, attempt one login. Also inspect the distribution’s PAM/authentication log and /var/log/vsftpd.log when that file is configured. The log line often identifies a PAM denial, a locked account or a user-list rejection that the client hides.
4. Inspect PAM and account state. Check /etc/pam.d/vsftpd, or the file named by pam_service_name. Then verify that the user exists, is not locked or expired, has the expected shell, and is not excluded by an access rule.
5. Read user-list and chroot settings as a separate policy. A known-good password can still be rejected by userlist_enable, and a successful authentication can still be followed by a chroot refusal. Change one setting at a time and retest.

Confirm vsftpd is reading the settings you changed

Check service health

systemctl status vsftpd should show an active service. If it is failed, fix the startup error before troubleshooting credentials. A syntax mistake, duplicate directive or wrong permissions on the configuration can prevent the intended settings from taking effect. systemctl cat vsftpd shows the unit definition, including any command-line option that points to an alternate configuration file.

#1 Best Overall

Mastering Linux Administration: Take your sysadmin skills to the next level by configuring and maintaining Linux systems

$49.99

Buy on Amazon

After an edit, restart or reload according to the service’s normal operating procedure and verify the result with systemctl status vsftpd. Do not assume that editing a similarly named file changed the live daemon. If several configuration files exist, record the exact path used by the service and make all subsequent checks against it.

Check the local-login switch

local_enable=YES

This directive permits local-user authentication. If it is absent or set to NO, every local username can fail even when the Linux password works for console, SSH or another service. This switch is independent of upload permission: leave write_enable=NO for a read-only FTP service, or set it to YES only for a deliberately writable use case.

Do not “fix” a login by enabling anonymous access. Anonymous FTP is a different authentication path and can expose data unintentionally.

Check PAM before resetting a password

vsftpd delegates much of local authentication and account authorization to Pluggable Authentication Modules (PAM). The directive pam_service_name tells vsftpd which PAM service definition to use. Inspect that named file; on many Linux installations it is /etc/pam.d/vsftpd.

Rank #2

UNIX and Linux System Administration Handbook

Buy on Amazon

Common PAM failure patterns

• Wrong service name: pam_service_name points to a file that does not exist or to a policy intended for another service.
• Missing or misordered module: a required module is not installed, has the wrong control flag, or is evaluated before a rule that should allow the account.
• Directory-service policy: LDAP, SSSD, winbind or another identity provider can deny an account even though a local password appears correct.
• Account restrictions: PAM may enforce expiry, access groups, time windows, denied users or shell restrictions. The FTP client may still receive only 530.

Reproduce one failure while following both journalctl -u vsftpd and the authentication log used by your distribution. A PAM message such as “account locked,” “authentication failure” or an access-module denial is more actionable than the client’s generic text. Avoid replacing the PAM stack with a copied example: PAM control flags determine whether a failed rule is fatal, and an apparently small edit can change policy for every FTP login.

Validate the Linux account itself

Confirm the name resolves

Check the account through the same identity mechanism the server uses, for example with getent passwd username. This tests local files and, where configured, directory services. If it returns nothing, vsftpd cannot authenticate that name through the expected source. Watch for spelling, case and a client that silently prepends a domain or email-style suffix.

Check lock and expiry state

Use your distribution’s account tools, such as passwd -S username for a concise password status and chage -l username for ageing and expiry information. An account can have the right password and still be denied because it is locked, expired, not yet active, or past a password-age limit. Directory accounts have equivalent status controls in the directory service; inspect those records rather than changing the local password.

Unlocking or extending an account is an administrative decision. Apply the smallest change that restores an intended account, document it, and retest. Do not disable expiry or account controls globally just to make one FTP login succeed.

Rank #3

Sale

How Linux Works, 3rd Edition: What Every Superuser Should Know

$46.59

Buy on Amazon

Check the login shell

Inspect the shell field returned by getent passwd username. When shell checking is enabled, vsftpd or the associated policy can reject a user whose shell is not listed in /etc/shells. This commonly affects service accounts assigned a non-interactive shell for security reasons.

Do not add an arbitrary shell to /etc/shells or globally relax shell checks without understanding the consequence: the file is also used by other programs to decide which shells are valid. If the account is intended for FTP only, choose an account policy that provides the required file access without granting an unintended interactive login.

Understand user-list allow and deny semantics

When userlist_enable=YES, vsftpd consults the file named by userlist_file. The commonly used default is /etc/vsftpd.user_list, but always read the value in the active configuration. The meaning of that file depends on userlist_deny:

Some configurations also use ftpusers or a distribution-specific deny file through PAM. Inspect those files and the PAM stack rather than assuming that changing vsftpd.user_list is sufficient. A user-list rejection can happen before password entry, which explains why a confirmed password still yields 530.

Rank #4

Linux Administration: The Linux Operating System and Command Line Guide for Linux Administrators

$2.99

Buy on Amazon

Keep chroot failures separate from authentication failures

chroot_local_user, chroot_list_enable and chroot_list_file control which local users are placed in a filesystem jail and how exceptions are interpreted. They do not replace password authentication. Troubleshoot them after PAM and account gates are working.

How the list interpretation changes

• With chroot_local_user=NO, local users normally are not jailed; when chroot_list_enable=YES, users in chroot_list_file are the exceptions that are jailed.
• With chroot_local_user=YES, local users normally are jailed; when the list feature is enabled, users in chroot_list_file are the exceptions that are not jailed.

Because the exception direction flips, read the two options together and test with a non-privileged account. A typo in chroot_list_file can make a user appear to receive different treatment from another account even though both authenticate successfully.

Fix the writable-root refusal safely

If the jail’s root directory is writable by the FTP user, vsftpd can stop with:

500 OOPS: vsftpd: refusing to run with writable root inside chroot()

The safer layout is a non-writable jail root owned by root, with a separate child directory that has the permissions needed for uploads. This preserves the boundary between the directory that defines the jail and the directory where files are written.

Best Value

Sale

The Linux Command Line, 3rd Edition: A Complete Introduction

$27.94

Buy on Amazon

allow_writeable_chroot=YES can suppress the refusal, but it is a deliberate security trade-off, not a universal login fix. The Debian vsftpd documentation warns that chrooting local users has security implications, especially when those users have upload permission or shell access. Decide whether the account needs a jail, whether it needs writes, and who owns each directory before enabling this option.

Use logs to identify the failing gate

Run a single controlled test rather than making several changes between attempts. A useful sequence is:

1. Open journalctl -u vsftpd -f.
2. Open the system’s PAM or authentication log in a second terminal.
3. Connect with one known account and record the exact username and time.
4. Capture the server’s response to the USER and PASS commands, without publishing the password.
5. Match the timestamp to the vsftpd and PAM entries, then change only the setting implicated by those entries.

When command-level detail is needed, enable vsftpd protocol logging temporarily using the logging directives documented for your installed version. Disable verbose protocol logging after diagnosis and protect log files, because usernames, paths and operational details can be sensitive. If no server-side entry appears, confirm that the connection is reaching this daemon and that a firewall, proxy or alternate FTP service is not returning the response.

Configuration choices and their consequences

FileZilla-specific checks

FileZilla reports the server’s FTP reply, so a line such as “530 Login incorrect” still points to server-side authentication or policy. In the site entry, verify that you are connecting to the intended host and FTP service, not an SFTP profile or a different server. Use the exact Linux or virtual-user name expected by the PAM configuration; do not assume that a desktop login name, email address or domain-qualified name maps automatically.

Open FileZilla’s message log and note the sequence around USER, PASS and the 530 response. Test once, then correlate the timestamp with journalctl and the PAM log. If the server log shows the account was denied before password verification, changing FileZilla’s password field cannot resolve it. If the server accepts authentication and then sends a 500 chroot refusal, correct the jail ownership and list semantics instead.

Recovery patterns for common symptoms

Every local account receives 530

• Verify the active configuration path and set local_enable=YES.
• Check that pam_service_name names the intended, readable PAM file.
• Watch PAM logs for a module or directory-service failure affecting all users.
• Inspect userlist_enable and userlist_deny; an allow-list mode with no entries can reject everyone.

One account receives 530 while another works

• Compare lock and expiry state with passwd -S and chage -l.
• Compare shell fields and verify the required shell appears in /etc/shells when shell checking is active.
• Search every configured user-list and PAM deny rule for the exact username.
• Check directory-service group or account restrictions if the user is not local.

Authentication succeeds, then the session fails

• Read the exact server reply: a chroot layout problem commonly says 500 OOPS, not 530.
• Inspect ownership and write permissions on the jail root and its writable child directory.
• Re-evaluate the interaction of chroot_local_user and chroot_list_enable before changing allow_writeable_chroot.

After the fix: make the result repeatable

Record the final configuration path, PAM service name, user-list mode and chroot policy. Keep a test account separate from administrative identities, and give it only the filesystem permissions required for its role. If uploads are enabled, retain a non-writable jail root and a dedicated writable subdirectory. Remove temporary protocol logging, restart or reload the daemon as appropriate, and perform one final login while confirming that the expected log entries appear.

The durable fix is the one that explains the original 530 in the logs: the correct local-login switch, a functioning PAM policy, a permitted account, an intentional allow/deny list, or a separate chroot correction. A password reset without that evidence can leave the real policy failure untouched.

Quick Recap

Bestseller No. 1

Mastering Linux Administration: Take your sysadmin skills to the next level by configuring and maintaining Linux systems

$49.99

Bestseller No. 2

UNIX and Linux System Administration Handbook

SaleBestseller No. 3

How Linux Works, 3rd Edition: What Every Superuser Should Know

$46.59

Bestseller No. 4

Linux Administration: The Linux Operating System and Command Line Guide for Linux Administrators

$2.99

SaleBestseller No. 5

The Linux Command Line, 3rd Edition: A Complete Introduction

$27.94

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.