How to enable Debug logging in CompleteFTP for troubleshooting

CompleteFTP logs at Information level out of the box, which is not enough to diagnose a connection, transfer or trigger failure. Almost every support investigation starts by asking for a log at Debug level covering the moment the problem happened. This article covers how to raise the level, where the log files actually are on Windows and on Linux, how to produce a log that only contains the problem, and the handful of reasons debug logging appears to do nothing.

This is about the CompleteFTP server. The edtFTPj/PRO and edtFTPnet/PRO client libraries have their own, unrelated logging API and are not covered here.

The short version

On Windows, using CompleteFTP Manager. On Linux there is no manager, skip to the command line below, which is the only interface there.

  1. Open CompleteFTP Manager and connect to the server.
  2. Go to the Monitoring panel, then the Log Files tab.
  3. Set Server logging level to Debug.
  4. Click APPLY CHANGES at the top of the window. This step is the one most often missed, until you click it the level has not changed on the server.
  5. Close the manager, so the server log isn't cluttered with the manager's own traffic.
  6. Reproduce the problem.
  7. Collect Diagnostics.log from the log folder (see the table below), zip it and send it.
  8. Set the level back to Information when you're done.

On Linux, using the command line, the only interface there. Run it as root or as the completeftp account, which are the accounts that can reach the server.

completeftp monitor set logging.level=Debug

The CLI applies the change itself, there is no separate apply step. Set it back with completeftp monitor set logging.level=Information.

To confirm either way worked, look in Diagnostics.log for the line the server writes when the level changes:

2026-07-30 11:42:07,412 INFO Server [Server.1] Logging level set to DEBUG

Where the log files are

The logging level is a single server-wide setting. It cannot be set per site or per user.

File Windows Linux
Server diagnostics C:\ProgramData\Enterprise Distributed Technologies\Complete FTP\Logs\Diagnostics.log /var/log/completeftp/Diagnostics.log
Warnings and errors only ...\Logs\Errors.log /var/log/completeftp/Errors.log
Audit log (off by default) ...\Logs\Audit.log /var/log/completeftp/Audit.log
Configuration changes ...\Logs\Config.log /var/log/completeftp/Config.log
CompleteFTP Manager's own log C:\Users\<username>\AppData\Local\EnterpriseDT\CompleteFTP\Logs\Diagnostics.log n/a

Two notes on that table, because both cost people time:

  • The manager's log folder is EnterpriseDT\CompleteFTP, with no space in CompleteFTP. The server's folder under ProgramData does have a space (Complete FTP). They are different, and some older instructions give the manager path with a space; that folder does not exist.
  • On Linux the log directory and its files are owned by the completeftp service account and are not world-readable. Read them as root (sudo cat /var/log/completeftp/Diagnostics.log) or add the reader to that account's group.

If CompleteFTP Manager is running on the same machine as the server, the Open logging folder link on the Log Files tab takes you straight there.

Rollover, and why the log you want may be gone

Diagnostics.log rolls by size: 5,000,000 bytes per file, 20 backups kept. Backups are Diagnostics.log.1 through Diagnostics.log.20, and .1 is the most recent rolled file, not the oldest. At Debug level on a busy server 100 MB of history can be minutes, so collect the log promptly after reproducing the problem.

Errors.log is much smaller: 10,000 bytes per file, 20 backups, about 200 KB of history in total. It records WARN, ERROR and FATAL, not only errors, so a server being scanned for logins fills it very quickly. Treat it as a quick glance, never as a history.

Audit.log rolls daily instead, with older files named Audit.log.YYYYMMDD.

To keep more history, override the log4net configuration rather than editing the shipped file, see "Changing the rollover limits" below.

Logging levels

Level What it gives you
Off Nothing.
Fatal Fatal errors only. Not offered in the manager's dropdown; settable via the CLI.
Error Errors.
Warning Warnings and errors.
Information The default. Logins, transfers, server start/stop. Not enough to diagnose a failure.
Debug What support asks for. Protocol handshakes, negotiated ciphers, FTP commands, SFTP messages.
All Everything, including raw protocol content. Noticeably slower, use only if Debug isn't enough.

Use exactly these spellings. They are the only values that survive a service restart: a non-canonical spelling accepted by the CLI (Warn, Info, Deb) is applied immediately but silently falls back to Information the next time the service starts, and leaves the manager's level dropdown blank in the meantime.

The full procedure

CompleteFTP Manager (Windows)

  1. Monitoring panel → Log Files tab.
  2. Set Server logging level to Debug.
  3. Click APPLY CHANGES.
  4. Close the manager. The manager is an admin client of the server, so leaving it open adds its own sessions to the log you are about to read.
  5. Reproduce the problem.
  6. Either use Open logging folder / Save to local disk, or copy Diagnostics.log directly from the path in the table above.

The same tab has a Save diagnostics link, which writes a zip containing Diagnostics.log and a copy of the configuration database. Be aware of exactly what that copy has stripped: user password hashes and encrypted passwords, SSL certificates, and the site's SSH host keys. Everything else is included as-is, user names, virtual-folder mappings, IP filters, and secrets held for other systems such as the SMTP password (encrypted, but present). The zip also holds only the current Diagnostics.log, not the rolled backups, so if the incident has already rolled out, copy the files by hand instead.

The Real-Time Logging tab

The Real-Time Logging tab shows recent messages live, which is often faster than reading a file. Its Display Level is capped by the server's logging level: it offers Error, Warning, Information and Debug, but only up to whatever the server is currently set to. If the server is at Information, Debug will not be in the list, raise the server level first. If the server is at Off, opening the list gives you:

Logging is currently turned off.  You can reenable it by changing the server's logging level in the Diagnostics tab.

The tab that message refers to is the one now labelled Log Files.

CLI. Linux

The CLI is the administration interface on Linux and works out of the box; the service unit starts with the admin channel enabled.

# show the current setting
completeftp monitor show logging

# raise it
completeftp monitor set logging.level=Debug

# reproduce the problem, then collect
sudo cp /var/log/completeftp/Diagnostics.log ~/diagnostics-$(date +%F).log

# put it back
completeftp monitor set logging.level=Information

The account matters: the CLI reaches the server over a Unix domain socket at /var/lib/completeftp/config/config.socket, which the service creates with mode 0770 owned by the completeftp user and group. Root and that account can open it; another account cannot, and gets a connection error rather than a permission message.

Restarting the service, if you need to:

sudo systemctl restart completeftp

CLI. Windows

The CLI is not enabled by default on Windows. If it is off, the service records

Admin CLI not enabled.

in Diagnostics.log at startup, and the CLI cannot connect. To enable it, add --enable-admin-cli to the service's binary path from an administrator command prompt:

sc qc CompleteFTP
sc config CompleteFTP binpath= "\"C:\Program Files\Complete FTP\server\CompleteFTPService.exe\" --enable-admin-cli"
sc stop CompleteFTP
sc start CompleteFTP

(Note the space after binpath=.) Then:

"C:\Program Files\Complete FTP\server\completeftp.exe" monitor set logging.level=Debug

The Windows admin CLI is local-only, it will not administer a remote server.

If you pass a value the CLI doesn't recognise it refuses the change:

Invalid logging level: Verbose

Use Debug or All.

Avoid setting the level through completeftp server set <name> logLevel=.... That path reaches the same field but does not validate the value, and an unrecognised value there stops the server logging altogether until it is restarted. Use monitor set logging.level= instead.

JSS (Enterprise MFT)

Over SSH to the admin site as the admin user:

var config = system.getConfig2();
config.monitoring.logging.level = "Debug";
config.applyChanges();

applyChanges() is required, the JSS config object behaves like the manager, not like the CLI.

Clustered servers

Each node keeps its own logging level and its own log files. Setting the level on the primary does not raise it on the secondaries, and the secondary's Diagnostics.log stays on the secondary. If the problem involves synchronisation, set the level on both nodes and collect both logs, matching them up by timestamp.

Producing a clean log

A log that spans hours of unrelated traffic is much less useful than one that covers only the failure. If you can stop the service briefly:

  1. Set the level to Debug, in the manager, remember APPLY CHANGES; from the CLI the change applies itself.
  2. Stop the CompleteFTP service (Windows: services.msc or sc stop CompleteFTP; Linux: sudo systemctl stop completeftp).
  3. Delete or rename Diagnostics.log. It cannot be deleted while the service is running.
  4. Start the service again.
  5. Reproduce the problem.
  6. Zip the log and send it.

If the service cannot be stopped, do steps 1, 5 and 6 only, and note the time the problem occurred so the relevant section can be found.

Before sending, open the file and check it covers the time the failure happened, and that it says DEBUG on its lines. A log that doesn't include the failure, or that is still at Information level, cannot be analysed and is the single most common reason a support round trip is wasted.

When it doesn't work

Ordered by how often it comes up in support tickets.

1. The level was set but not applied. In the manager, changing the dropdown does nothing until APPLY CHANGES is clicked. If the button is still enabled, the change hasn't reached the server. Confirm by looking for Logging level set to DEBUG in Diagnostics.log.

2. The log is still at Information level. Check the level column of the lines themselves, you should see DEBUG lines, not only INFO. If you set the level after the failure, the log covering the failure is still at the old level; the level is not retroactive. Reproduce the problem again.

3. The log is not generating at all. Two causes, in this order:

  • The account running the CompleteFTP service (SYSTEM by default on Windows, completeftp on Linux) lacks write permission to the log directory. On Windows it needs write access to C:\ProgramData\Enterprise Distributed Technologies\Complete FTP\Logs, and also to config.db, Users and Backups in the parent folder, if it can't write config.db your logging-level change cannot be saved either, which looks like the setting refusing to stick.
  • You are looking at the manager's log instead of the server's, or vice versa. They are different files in different places (see the table).

4. The log was overwritten before you collected it. See "Rollover" above. At Debug level on a busy server the 20 × 5 MB budget can be consumed quickly. Collect promptly, or raise the limits first.

5. Nothing appears for the connection attempt. If a client connects and no session line appears at Debug level, the client is not reaching CompleteFTP at all, a firewall, a NAT rule, or a port conflict. Test from the server machine itself with a known-good client against localhost; if that works and the remote client doesn't, the problem is in the network path, not in CompleteFTP. Connecting on the wrong port produces the same silence: SFTP is on 22 and the admin site on 14983 by default, and two listeners cannot share a port.

6. The level reverted after a service restart. You set a non-canonical spelling through the CLI or JSS. Use exactly Off, Fatal, Error, Warning, Information, Debug or All.

7. The Real-Time Logging tab won't let you select Debug. Its display level cannot exceed the server's logging level. Raise the server level on the Log Files tab first.

8. You can't reach the manager at all. If the manager won't connect, that is a separate problem and needs the manager's log: in the connect dialog choose Other settings..., set the manager logging level to Full diagnostic (slow), retry the connection, and send C:\Users\<username>\AppData\Local\EnterpriseDT\CompleteFTP\Logs\Diagnostics.log.

Reading the output

Diagnostics lines are date level logger message, with a tag in square brackets identifying what the message is about:

2026-07-30 11:42:07,553 DEBUG ServerKeyExchanger [Session.128:Default Site.22:ftpuser:192.168.1.50] Decided cipher C->S= AES_CTR_256

The session tag is Session.{n}:{site-name}.{port}:{user-name}:{remote-IP}, so you can follow one client through the file by grepping its session number. Other tags you will see include Server.{n} for start/stop, Cluster.{...} for cluster synchronisation, IPFilter.{n} for filtering decisions, and Crontab.{n} for scheduled events.

Things worth knowing when reading a Debug log:

  • FTP and FTPS commands appear as CMD> <command> lines. PASS is masked, the log shows PASS ********. Commands are truncated at 80 characters, with [+N characters] appended, so a long path in a command may be cut off.
  • SFTP has no command log, because SFTP clients send messages rather than commands. You will see message types being processed instead. There is no way to get a commands-only log; that is a property of how the logging is structured, not a setting.
  • The negotiated SFTP cipher is on ServerKeyExchanger lines: Decided cipher C->S=, Decided cipher S->C=, Decided MAC C->S=, and Decided hostkey alg=.
  • The negotiated FTPS/TLS cipher suite is on EdtTlsServer lines: Handshake complete. Selected cipher suite: ..., alongside Server cipher suites: and Offered client cipher suites:. Older instructions point at a ServerHandshakeLayer line containing m_EncryptionScheme=, that no longer exists; the TLS stack was replaced. If you set Debug and couldn't find the cipher, you were looking for the wrong string.
  • Config.log records every configuration change and which admin user made it, so it will show your logging-level change too.

Debug logging in production

The guide's warning is worth repeating: Debug and especially All produce a large volume of output and can have a significant impact on performance. In practice:

  • Turn Debug on for as short a window as you can, long enough for a client to reproduce the problem, and set it back to Information afterwards.
  • Prefer Debug over All. All includes raw protocol content and is markedly slower; only go there if Debug genuinely lacks the detail.
  • Changing the logging level does not restart the service and does not drop connections. It takes effect immediately when applied.
  • If what you actually need is a durable record of who logged in and what they transferred, enable auditing instead, it is far cheaper than Debug logging and designed to be left on. The link is Configure auditing on the same Log Files tab, or completeftp monitor set auditing.enabled=true.
  • Debug logs contain user names, client IP addresses, file paths and site names. They do not contain passwords. Treat them as sensitive when sending them anywhere.

Changing the rollover limits

Do not edit CompleteFTPService.exe.config in the install directory, an upgrade will overwrite it. Instead create LogConfig.xml in the log directory (...\Complete FTP\Logs\LogConfig.xml on Windows, /var/log/completeftp/LogConfig.xml on Linux), copy the <log4net> node from C:\Program Files\Complete FTP\Server\CompleteFTPService.exe.config into it, adjust MaximumFileSize and MaxSizeRollBackups on the Recent Logging Messages appender, and restart the service. The same file is how you add a syslog or Windows Event Log destination, or change the log file location.

Related

Other technical articles

Download Free Trial