An FTP service can appear to be installed and still be unavailable to users because it is stopped, listening on the wrong interface, blocked by a firewall, or failing during startup. Knowing how to check ftp server is running in linux helps you separate those problems quickly instead of guessing at configuration changes. The most reliable approach is to check the service manager first, then confirm that the server process is listening on the expected port, and finally test connectivity from the local machine or a remote client.
Linux distributions may use different FTP servers, including vsftpd, ProFTPD, and Pure-FTPd, so the exact service name can vary. Systemd-based distributions such as Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, and Fedora provide the simplest checks through `systemctl`. Older systems may use `service` commands instead. This article shows practical commands for both situations, explains what normal and failed output looks like, and covers common issues that prevent an FTP server from accepting connections.
Checking the FTP Service With systemctl
On most current Linux distributions, `systemctl` is the fastest way to see whether an FTP service is running. Start by identifying the FTP daemon installed on the server. For vsftpd, which is widely used because of its straightforward configuration and security options, the service is usually named `vsftpd`.
Run the following command:
`sudo systemctl status vsftpd`
A healthy service normally displays `active (running)` in green or plain text, followed by the process ID, startup time, and recent log lines. If the status shows `inactive`, `failed`, or `not found`, the service is not currently available under that name.
For ProFTPD, use this command instead:
`sudo systemctl status proftpd`
Pure-FTPd installations may use either `pure-ftpd` or `pure-ftpd.service`, depending on the distribution package. You can try:
`sudo systemctl status pure-ftpd`
If you do not know which daemon is installed, list
`systemctl list-units –type=service –all | grep -i ftp`
Checking Whether the Service Starts Automatically
A running FTP server can stop after a reboot if it is not enabled. Check its boot-time setting with:
`sudo systemctl is-enabled vsftpd`
The result `enabled` means systemd will start the service during boot. A result of `disabled` means it must be started manually or enabled with the following command:
`sudo systemctl enable vsftpd`
This command changes only the startup behavior. To start
`sudo systemctl start vsftpd`
Useful service status results include:
- `active (running)` means the daemon is running normally.
- `inactive (dead)` means the service is stopped but has not necessarily encountered an error.
- `failed` means systemd attempted to start the service and encountered a problem.
- `activating` means the daemon is still starting.
- `Unit vsftpd.service could not be found` usually means vsftpd is not installed or uses a different service name.
Confirming That FTP Is Listening on Its Network Port
A service can report as running while still failing to accept FTP connections. The next check is whether the daemon is listening on TCP port 21, the standard FTP control port. Modern Linux systems commonly include either `ss` or `netstat` for inspecting open sockets.
Use `ss` first:
`sudo ss -tulpn | grep ':21'`
Expected output resembles this:
`tcp LISTEN 0 32 0.0.0.0:21 0.0.0.0:*
This confirms that an FTP daemon is listening on all IPv4 network interfaces. If the address is `127.0.0.1:21`, the server accepts connections only from the local machine. Remote users will not be able to connect until the service is configured to listen on an external interface.
On systems where `net-tools` is installed, you can use:
`sudo netstat -tulpn | grep ':21'`
You can also inspect a particular process with `lsof`:
`sudo lsof -iTCP:21 -sTCP:LISTEN`
The listening process should match the FTP daemon you expect. If another process owns port 21, your FTP service may fail to start or may have been configured to use a different port.
Verifying the Local FTP Response
Checking an open socket is useful, but a local connection test confirms that the daemon responds to FTP commands. You can use Telnet, Netcat, or an FTP client from the server itself.
With Netcat, run:
`nc -vz 127.0.0.1 21`
A successful result generally says that the connection to port 21 succeeded. To see the FTP greeting banner, use:
`nc 127.0.0.1 21`
A working server often returns a line similar to:
`220 (vsFTPd 3.0.5)`
Type `QUIT` and press Enter to close the session cleanly. If the connection is refused, no process is listening on that address and port. If it times out, a local firewall rule or unusual networking setup may be involved.
Quick local verification checklist:
1. Run `sudo systemctl status vsftpd` and confirm the service is active.
2. Run `sudo ss -tulpn | grep ':21'` and confirm port 21 is listening.
3. Run `nc -vz 127.0.0.1 21` to verify the local TCP connection.
4. Check that the FTP banner appears if you connect with Netcat.
5. Test from a separate machine to confirm that network access is available.
Testing the FTP Server From Another Machine
A local test proves the daemon is alive, but it does not confirm that clients on your network can reach it. From another Linux, macOS, or Windows system, test the server by using its IP address or hostname.
For a basic port check from another Linux machine, run:
`nc -vz server-ip-address 21`
Replace `server-ip-address` with the server’s actual private or public address. A successful connection indicates that the network path and port access are working. A timeout often points to a firewall, cloud security group, router rule, or an incorrect IP address.
You can also use an FTP client:
`ftp server-ip-address`
If the connection succeeds, the client should display the server banner and prompt for a username. This does not guarantee that login credentials or directory permissions are correct, but it confirms that the FTP control connection is available.
Distinguishing Connection Errors
The exact error message provides useful direction. “Connection refused” normally means the destination host was reached, but no service is listening on port 21 or a firewall is actively rejecting the request. “Connection timed out” usually means traffic is being silently dropped somewhere between the client and server.
A successful TCP test followed by failed file transfers is a different issue. FTP uses a control connection and separate data connections. Passive mode, firewall rules, NAT, and the configured passive port range may need attention. [Internal Link: FTP passive mode configuration] can help you diagnose that stage of the connection.
Reviewing FTP Server Logs
Service logs often reveal why an FTP server stopped, failed to start, or rejected a connection. On systemd systems, `journalctl` is the first place to check. For vsftpd, run:
`sudo journalctl -u vsftpd –no-pager -n 50`
This displays the most recent 50 log entries for the service. Add `-f` to follow new log messages while you start the service or attempt a client connection:
`sudo journalctl -u vsftpd -f`
Typical startup issues include syntax errors in the configuration file, duplicate options, invalid file paths, unavailable TLS certificate files, and port conflicts. The log output is usually more specific than the brief `failed` status displayed by `systemctl`.
Some distributions also record FTP activity in files under `/var/log`. Common locations include `/var/log/vsftpd.log`, `/var/log/xferlog`, `/var/log/messages`, and `/var/log/syslog`. The exact location depends on the daemon and distribution.
Checking Recent Service Failures
Use this command to view details from the most recent
`sudo systemctl status vsftpd -l`
The `-l` option prevents systemd from shortening long log lines. You can also inspect the extended journal for the current boot:
`sudo journalctl -xeu vsftpd`
Read the lines immediately after the service startup attempt. They often name the setting or file responsible for the failure. Correct that specific issue before repeatedly restarting the service, because repeated restarts without reading the logs rarely identify the root cause.
Common log clues include:
- `500 OOPS` messages often indicate an unsafe directory ownership or permission setting.
- `bind: Address already in use` means another process already owns the configured port.
- `cannot load certificate` points to a missing, unreadable, or invalid TLS certificate file.
- `permission denied` may indicate that the daemon cannot access its configuration, log, upload, or chroot directory.
- `unknown config option` usually means a directive is unsupported by that FTP server version.
Checking Firewall Rules for FTP Access
A running server that listens on port 21 can still be inaccessible from outside the host. Check the active firewall before changing the FTP configuration. The command depends on the firewall tool used by your Linux distribution.
On systems using UFW, check the rules with:
`sudo ufw status verbose`
Allow the FTP control port if it is missing:
`sudo ufw allow 21/tcp`
On systems using firewalld, inspect enabled services and
`sudo firewall-cmd –list-all`
To allow the predefined FTP service permanently, run:
`sudo firewall-cmd –permanent –add-service=ftp`
Then reload the firewall configuration:
`sudo firewall-cmd –reload`
For a server using passive FTP, opening port 21 alone is usually not enough. You must also allow the passive port range configured in the FTP daemon. For example, if vsftpd uses ports 30000 through 31000 for passive data connections, that entire TCP range must be allowed.
Firewall checks that prevent common mistakes:
- Confirm the firewall is active before assuming it is the cause.
- Open only the control port and passive range your FTP configuration actually uses.
- Check cloud provider security groups or network firewalls separately.
- Verify router port forwarding when the server is behind NAT.
- Test from an external client after each firewall change.
Checking vsftpd Configuration and Service Health
vsftpd is commonly configured through `/etc/vsftpd.conf`, although some distributions use additional files in `/etc/vsftpd/`. Before editing anything, make a backup and inspect the currently active settings.
You can view non-comment configuration lines with:
`sudo grep -vE '^\s*#|^\s*$' /etc/vsftpd.conf`
Important settings may include `listen=YES`, `listen_ipv6=YES`, `local_enable=YES`, `write_enable=YES`, and passive mode options such as `pasv_min_port` and `pasv_max_port`. The correct choices depend on whether users need local accounts, uploads, anonymous access, or remote access through a firewall.
After changing the file, restart the server:
`sudo systemctl restart vsftpd`
Then immediately check its state:
`sudo systemctl status vsftpd`
A configuration typo may cause the restart to fail even if the service was working before. That is why checking status and logs directly after a change is safer than waiting for users to report an outage.
Verifying the Correct Listening Address
The `listen` settings determine which protocol and interfaces vsftpd uses. A server listening only on localhost is useful for some proxy arrangements, but it will not serve remote FTP clients directly. Confirm the active address with `ss`, rather than relying only on the configuration file.
For example, this output means the service listens only
`tcp LISTEN 0 32 127.0.0.1:21 0.0.0.0:*`
This output means it accepts IPv4 connections on all
`tcp LISTEN 0 32 0.0.0.0:21 0.0.0.0:*`
An IPv6-only listener may display `[::]:21`. Depending on the operating system and network configuration, IPv4 clients may not be able to use that listener. Test with the same address family your users will use.
Managing ProFTPD and Pure-FTPd Services
The same general checks apply to ProFTPD and Pure-FTPd. Start by checking the service unit, then inspect port 21 and test an actual connection. Package names, service names, and configuration locations differ, so do not assume commands written for vsftpd apply unchanged.
For ProFTPD, common commands include:
`sudo systemctl status proftpd`
`sudo systemctl restart proftpd`
`sudo journalctl -u proftpd –no-pager -n 50`
Its main configuration file is often `/etc/proftpd/proftpd.conf`. ProFTPD supports a flexible module-based configuration, so errors may occur in included files rather than the main file.
Pure-FTPd may be managed through `pure-ftpd`, `pure-ftpd-mysql`, or distribution-specific service units. Use the following command to locate likely units:
`systemctl list-unit-files | grep -i pure`
Once you identify the correct service, use the same status, journal, socket, and network checks described earlier.
Comparison of Common FTP Server Checks
| Task | vsftpd | ProFTPD | Pure-FTPd |
|—|—|—|—|
| Check service | `systemctl status vsftpd` | `systemctl status proftpd` | `systemctl status pure-ftpd` |
| Restart service | `systemctl restart vsftpd` | `systemctl restart proftpd` | `systemctl restart pure-ftpd` |
| View logs | `journalctl -u vsftpd` | `journalctl -u proftpd` | `journalctl -u pure-ftpd` |
| Check port 21 | `ss -tulpn \| grep ‘:21’` | Same command | Same command |
| Common configuration path | `/etc/vsftpd.conf` | `/etc/proftpd/proftpd.conf` | Distribution-specific |
Troubleshooting Failed FTP Login Attempts
A server can be fully operational while user login attempts fail. Separate connection problems from authentication and authorization problems. If a client reaches the FTP banner and receives a username prompt, the FTP daemon is running. At that point, inspect account credentials, access policies, and directory permissions.
For local Linux users on vsftpd, `local_enable=YES` must usually be enabled. For uploads or file changes, `write_enable=YES` is also commonly required. Chroot settings can restrict users to their home directory, which is often desirable, but they can trigger errors if directory ownership and write permissions are not configured safely.
Check the server logs while attempting a login. They may reveal whether the account is denied, the password is incorrect, PAM authentication failed, or the home directory cannot be accessed. Avoid weakening permissions blindly to make the error disappear. Secure ownership and a dedicated writable subdirectory are often better solutions.
Handling Passive Mode and Data Connection Failures
Many FTP problems occur after a successful login, when users try to list directories or transfer files. This usually points to the FTP data channel rather than the server’s basic running state. Passive mode is common for clients behind NAT or firewalls because the client initiates both connections.
For vsftpd, a typical passive configuration may look like
`pasv_enable=YES`
`pasv_min_port=30000`
`pasv_max_port=31000`
`pasv_address=your-public-ip-or-hostname`
The firewall must permit TCP port 21 and the selected passive range. If the server is behind a router, the router must forward the same ports to the FTP host. The `pasv_address` value must be reachable by clients, not merely valid on the local network.
A practical troubleshooting sequence is:
1. Confirm that port 21 is reachable from the client.
2. Log in and try listing the remote directory.
3. Check the FTP daemon log during the failed operation.
4. Verify the configured passive port range.
5. Allow the same range in the host firewall and any cloud firewall.
6. Confirm public IP or hostname settings when NAT is involved.
7. Retest with a standard FTP client such as FileZilla.
Security Considerations Before Exposing FTP
Standard FTP sends usernames, passwords, and file data without encryption. It may be acceptable on a tightly controlled private network, but it is a poor choice for internet-facing transfers. If remote access crosses an untrusted network, configure FTPS or use SFTP instead.
FTPS adds TLS encryption to FTP but retains FTP’s separate control and data connection behavior. SFTP is a different protocol that runs over SSH, commonly on port 22. It is often easier to firewall and maintain because it uses a single encrypted connection.
If you are deciding between these options, [Internal Link: SFTP vs FTP] is a useful next reference. Do not assume that enabling SSH automatically enables FTP, or that installing an FTP server creates SFTP access. They are separate services with different configurations.
Routine FTP Server Monitoring Tips
Checking the service manually is useful during setup and troubleshooting, but recurring monitoring helps prevent downtime from lingering unnoticed. A basic monitoring check can verify that the systemd unit is active, port 21 is listening, and a local connection receives an FTP banner.
For simple scripts, `systemctl is-active –quiet vsftpd` returns a successful exit code only when the service is active. Monitoring platforms can use that result and alert when the service stops. For stronger coverage, add a remote connection test from a separate host.
Keep an eye on disk space, file permissions, log growth, certificate expiration for FTPS, and failed login attempts. A server may technically be running while being unable to store uploaded files or accept authenticated users. Service health should include the entire path users depend on, not only the process state.
Conclusion
The quickest way to verify an FTP server is to check its service status with `systemctl`, confirm that a process is listening on port 21, and test a connection locally and from another machine. Those three checks identify most outages without requiring guesswork. If the service is failed, use `journalctl` and the service status output to find the specific configuration or startup error.
When the service is active but remote clients cannot connect, focus on firewall rules, cloud security settings, routing, and the address on which the daemon is listening. Successful login followed by failed directory listings or transfers usually points to passive mode and its port range. For security, avoid exposing unencrypted FTP on public networks when FTPS or SFTP is available. Once you know how to check ftp server is running in linux, you can diagnose service, network, and configuration problems in a logical order and restore access faster.
Frequently Asked Questions
Is FTP running if systemctl shows active?
Usually, yes. An `active (running)` status confirms that systemd considers the daemon operational. Also verify that port 21 is listening and test a connection, because a running process may still be inaccessible to remote clients.
Which port does an FTP server use?
FTP normally uses TCP port 21 for control connections. Passive FTP also uses a separate configured range of TCP ports for file transfers and directory listings, so port 21 alone may not be sufficient.
Why does FTP connection get refused?
Connection refused usually means the host is reachable but no process is listening on port 21. Check the FTP service status, confirm the listening socket with `ss`, and verify that the daemon uses the expected port.
How can I restart vsftpd?
Run `sudo systemctl restart vsftpd` on a systemd-based Linux distribution. Immediately check `sudo systemctl status vsftpd` afterward, because a configuration error can prevent the service from starting successfully.
Is SFTP the same as FTP?
No. SFTP uses SSH and normally runs through port 22, while FTP is a separate protocol that commonly uses port 21 plus data ports. SFTP is generally easier to secure for remote file transfers.