Cerberus FTP Server Logs Check Who Connected Uploaded and Failed

Almost every Cerberus question is answered in its log - why a login failed, whether a file really uploaded, who downloaded a folder, and whether someone is guessing passwords at night. Cerberus shows live activity in Server Manager and keeps log records you can review afterwards. Make a habit of opening the log after every setup change and after every user complaint. Guessing wastes the time the log would have saved.

1. A normal session shows the connecting IP, the username, login success, each command in plain words - listing, upload, download, delete - and a disconnect. Learn this shape while things are healthy, so abnormal looks obvious later.
2. A failed login shows the attempted username and the failure reason the server recorded. Wrong password, disabled account and insecure connection refused are three different fixes - the log tells you which one you have.
3. A login that succeeds followed by a failed upload is usually a folder permission problem, not a network problem. The log separates those layers cleanly if you read it in order.
4. In the FTP client, matching reply codes help too - 230 means logged in, 530 means login rejected, 550 means logged in but not allowed to do that action.

An internet facing file server will be probed. The log pattern is unmistakable once you have seen it - the same IP, or a rotating set of IPs, failing login after login with names like admin, test or real staff names, often for hours.

1. Confirm your defences are on - account lockout after repeated failures, strong passwords, and require secure connections so captured attempts reveal nothing useful.
2. Use Cerberus IP controls where available to block or allow by address for your use case, and keep internet exposure as narrow as the internet exposure page in this series describes.
3. Do not panic over a handful of failed logins from a known user who mistyped. Volume, unknown IPs and valid usernames being targeted are what raise the level.
4. Keep the log excerpt if you need to report the activity. Times, IPs and usernames are the evidence - your memory of it is not.

The other daily use of logs is settling honest disputes. A client says a file was sent; your team says it never arrived. The log shows the upload with time, user, file name and result, or it shows no such event - both answers end the argument politely. Train the habit of checking before re sending large files or blaming the network. Where your edition offers reporting or log export, keep logs for the period your office policy or client contracts require, and protect the log store like any other record - it contains user behaviour, not just machine data.