I deployed the same small PHP and MySQL application to four free hosts in September. Three failures looked familiar enough that I nearly fixed the wrong thing: an FTP login error, an FTP permission error, and a database timeout. The words in each error described what the client saw, not the layer that failed.
The useful question was not “What does this error code usually mean?” It was “Which step had already succeeded before this error appeared?”
1. 530 Login authentication failed with the correct password
On ProFreeHost, I copied the FTP credentials from the control panel into a client. Login returned:
530 Login authentication failed
I had no reason to think the password was wrong, but that message gave me no other lead. Re-entering it did not help. Changing the connection mode did: the server rejected plaintext FTP and accepted the same username and password with explicit FTPS (FTP over TLS, starting on the usual FTP port).
The discriminating test was to hold the credentials constant and change only TLS. If the same credentials work over FTPS, resetting the password would have addressed the wrong variable. This does not mean every 530 is a TLS problem; it means 530 alone does not establish that a password is wrong.
2. 425 Operation not permitted after login worked
On AwardSpace and FreeHostingEU, the FTPS login succeeded. I could change directories. Then every file transfer failed:
425 Unable to build data connection: Operation not permitted
“Operation not permitted” sounds like a directory permission problem. But directory changes and authentication were already working. The step that changed was opening the data connection for the upload. FTP uses a control connection for commands and a separate connection for file data; a successful login says little about the latter.
These servers required the data connection to resume the control connection's TLS session. Python's ordinary ftplib.FTP_TLS opened a fresh TLS session for data, and the server refused it. In my deploy script, a small FTP_TLS subclass passes session=self.sock.session when wrapping the data socket; transfers then proceed. The fix belongs at the data-channel TLS handshake, not in a panel checkbox for file permissions. A client that supports TLS session reuse can solve the same problem without custom Python.
I would not generalize this behavior to every FTPS server. ProFreeHost did not require this change; the AwardSpace pair did. Also, FTPS has two separate settings to check: use TLS for the control connection, and request protection for the data connection (prot_p() in Python).
3. A MySQL timeout caused by the address itself
ProFreeHost's panel supplied a MySQL hostname, sql301.ezyro.com. A local database client timed out trying to connect. That initially looked like a blocked port or a firewall rule. I checked DNS before changing either:
sql301.ezyro.com -> 192.168.0.191
That is a private IPv4 address, not a route to a database from my laptop. I checked it again on October 23 and got the same address. The hostname works for code running inside the host's network; it is not an invitation to connect from the public internet. For this account, the workable paths were PHP running on the host or phpMyAdmin in its panel, rather than a local MySQL client.
A timeout can come from many places. This one did not require guessing: the DNS answer showed that the destination was unreachable from where I was running the client.
The check I now do first
For an FTP or database failure, I write down the last step that worked:
| Last successful step | Next thing to inspect |
|---|---|
| FTP credentials entered, login refused | Compare plaintext FTP with explicit FTPS using the same credentials |
| FTPS login and directory change worked, upload failed | Inspect the data connection, including TLS protection and session reuse |
| Database hostname resolves, connection times out | Inspect the resolved IP before changing passwords or firewall rules |
These were observations from specific accounts, not universal meanings for 530, 425, or a timeout. The point is to change one variable at a time and follow the protocol stage that actually failed.
For the full ProFreeHost deployment record—including the original 530, the private MySQL address, and what happened after the files finally uploaded—I kept the measured application and host notes together. The three diagnostics above stand on their own; that record is for anyone who wants to inspect the larger test.
Top comments (0)