The FTP server is currently refusing every connection from any user on any listener (FTPS and HTTPS is configured). The server response is: “421-User access not allowed. Max user limit reached for server.”
This situation emerged after I was doing a bulk file operation. First I got banned (based on IP address). Later the ban was expired, but no login is possible with whatever user account.
Even after restarting the underlying Integration Server the problem still persists. In the Active Transfer admin UI (luckily, this is still accessible), I’ve also increased the “Maximum simultaneous user connections” (under “Listener preferences”/“Throttling”) to unlimited.
Somehow the old, stale sessions seem to congest the server. How can I drop/purge these sessions?
Error messages / full error message screenshot / log file:
The message from the server is: “421-User access not allowed. Max user limit reached for server.”
421 is also the HTTP response status code on the FTP control connection.
I couldn’t find anything related to this problem in the log files. Only the ban was reported in ActiveTransfer.log.
421-User access not allowed. Max user limit reached for server.
This limit seems to be on the server-side (FTP Host) and not on the client (i.e., MFT).
The FTP server’s licence limits the user sessions (perhaps its a free version?) and assuming that your MFT server is not the only client, then a licence upgrade is required to allow more sessions.
Else if your MFT server is the only client, then you can do 2 things -
Reach out to the FTP server admin and get them to terminate your user’s sessions
Check if there are any open threads on the underlying MFT IS and cancel/kill them (obviously not a recommended option, but the 1st step alone should be sufficient)
I haven’t been precise enough at describing my setup. I’m using Active Transfer as FTP server (Integration Server package WmMFT). There is no additional FTP server behind this. The virtual folders of Active Transfer are hosted on the local file system, not on a remote storage location (such as an FTP server or cloud storage). I have full access to the Active Transfer admin UI, the underlying Integration Server, and the operating system (Ubuntu).
Regarding your suggestions:
Since there is no other FTP server involved, I guess, I should search for the user sessions on the Active Transfer server. Can I inspect/terminate these sessions somewhere in the Active Transfer admin UI or the underlying Integration Server?
I’ve shut down the Integration Server and looked for any remaining processes/threads. There was no such leftover. After starting the Integration Server again, the problem is still present: Users can’t log into the services (FTPS, WebDav/WebClient on HTTPS) provided by the Active Transfer server. The server’s response is still the mentioned 421 message.
Dear Kasi,
here’s an update regarding your latest suggestions:
I’ve increased the number of connections to 20 in the JDBC pool. That didn’t seem to be the bottleneck
The property mft.server.maxThreads doesn’t exist on my instance. I’ve checked it both in the configuration file and through the admin service you’ve mentioned.
Anyway, thank you very much for your dedicated help! Now I’m going to dig deeper into the file system and into the database attached to the Integration Server.
Recreating the database component ActiveTransfer (ACT) with the Database Component Configurator. Importing the previously exported Active Transfer Server assets afterwards to restore the server configuration.
Deleting and reinstalling the Integration Server package wmMFT.
Unfortunately, both approaches didn’t change anything. I’m going to open a support ticket now.
For anyone running also into such 421 error: I guess a plain restart of the Integration Server or a reboot of the OS is already sufficient. But don’t set the maximum simultaneous user connections to unlimited (by deleting the number in the ActiveTransfer server admin UI)! The UI says unlimited, but for the backend it’s literally zero. This makes the 421 error really persistent. A future fix might remove this obstacle, but as of now, don’t set the maximum simultaneous user connections to unlimited!
I can’t say whether any additional step beside restarting/rebooting the system was really necessary for fixing the problem. But in case of trouble, try the actions recorded in this discussion (except setting maximum simultaneous user connections to unlimited).
you’re welcome! If you have a question not related to an existing topic, you can create a new thread by clicking on + New Topic on the main page. Provide the necessary context there.
