Support

Akeeba Backup's FTP code hasn't changed in the last three years. PHP's FTP implementation hasn't changed in way longer than that.

First of all, the FTP test will not be able to write to your NAS if your initial directory connects to Synology's FTP root. You can't write to Synology's FTP root; it's a virtual directory listing all shares you have access to. You can only write into specific "directories" under that FTP root, each directory representing a share you can see with the user you have connected to.

Further to that, it is very easy to create a situation where you can connect to a share on your Synology NAS over FTP but have to write permissions. I would start diagnosing this at the NAS side, even if you think nothing changed. Make sure the user you are connecting with has explicit write permissions to the share on your Synology NAS.

Beyond that, I am not sure that you are diagnosing the issue correctly. Is it really a message from your NAS recorded in the backup log file saying that you are not allowed to write to the share you are using, or was it an assumption you made? Have you maybe configured the wrong directory (they are case-sensitive)? Is it a timeout? Have you maybe forgotten to use Passive mode when setting up the connection in Akeeba Backup?

DEBUG   |20260315 14:22:29|Loading post-processing engine object (none)

This says you have not enabled any post-processing in the backup profile you used.

The new log file also says that you have not set up FTP. The post-processing engine is still set to none.

There is a reason I am asking for a log file with the FTP engine enabled. Depending on your Synology NAS configuration it is possible that testing the FTP connection succeeds the connection but fails the upload (as you described) but it will still work when uploading the backup. I have a Synology NAS I tested it with before replying to you the first time, so I know it still works – like it's been working for well over a decade I've had a Synology NAS to play with.

Before sending you down the wrong path, I would REALLY like to make sure your problem is not just a misunderstanding of how the FTP test works with a Synology NAS.

Good, we now have the correct engine. FYI, this is the line:

DEBUG   |20260316 10:28:24|Loading post-processing engine object (ftp)

The "Loading post-processing engine object" is unique in the log file, and what I search when trying to see if the correct engine is loaded. The stuff between the parentheses is the name of the engine. Now you know my trick ;)

There were two reasons I needed the log file. Many people confuse FTP and SFTP. They are entirely different protocols with entirely different requirements on either end of the connection, so I needed to be absolutely sure I am talking about FTP, not SFTP. We got that.

The second reason is that the log file tells me at which point of the FTP file transfer we get a problem. This log file tells us that we have successfully connected to the FTP server (the login is successful), but the FTP server has rejected our file upload. This meshes well with your FTP test.

As a result, we have to consider three things:

1. Passive vs Active mode
2. Correct initial directory
3. Any possible hosting interference.

First, understand that FTP uses two separate connections between the client and the server: a control channel for sending commands and receiving replies (we have verified this is connected), and a data channel for transferring files or directory listings. The control channel stays open for the whole session, while the data channel is opened only when a transfer is needed and then closed again.

Next, we need to consider how the data channel connection is established. There are two modes: active and passive.

Active mode. In this arrangement the client opens a socket on a random high‑numbered port and tells the server, via the control channel, which port it is listening on. When the server is ready to send or receive data, it initiates a connection from its own data port (normally port 20) back to the client’s specified port. This works well when the client is directly reachable from the internet, but it can be blocked by firewalls that prevent inbound connections. This mode rarely works on commercial web hosting because these ports are firewalled by default.

Passive mode. Here the client asks the server to listen for a data connection. The server replies with the address and port number it has chosen. The client then initiates the data connection to that server‑provided endpoint. Because the client is the one that opens the connection, passive mode usually works better through firewalls and NAT devices, which tend to allow outbound connections but restrict inbound ones. This is what most always works on commercial web hosting.

With that in mind, here's what you need to check.

In the Configuration page make sure that Use passive mode is set to Yes.

Again in the Configuration page make sure that the Initial directory is set to your share's name without a leading slash. Also note that it is case-sensitive, i.e. FOOBAR, foobar, and FooBar are three different shares.

On your Synology side, log in and go to the Control Panel applet. Click on Shared Folder. Click on the share. Click on Edit. Click on Permissions. Find the username you are connecting as. You need a tick mark under Read/Write. Also make sure that Advanced Permissions are all disabled.

Now try a backup. If it worked, stop. If it did not, keep reading.

Connect to your FTP server using the SAME connection information you are using in Akeeba Backup from outside of your own network. A simple way to do that is disconnecting from your home/office Ethernet and WiFi, then tethering your computer to your phone's data (5G, 4G, …) connection. Can you upload, download, and delete a file? If not, you have messed up your Synology configuration. If you can and you still have a problem then the problem lies with your host.

By default, the Linux kernel won't allow FTP passive mode connections to be established. This requires loading a kernel module, adjusting kernel configuration parameters, and adding a firewall rule. Because the environment you are working in is a commercial hosting platform, you do not have the necessary root privileges on the server to do that yourself. The practical step is to contact your hosting provider’s support team, explain that you need passive‑mode FTP to be allowed, and ask them to please help.

For what it's worth, here's the slightly more technical take on FTP passive mode in Linux. Linux kernels include a Netfilter helper called nf_conntrack_ftp that is required for the firewall to recognise and allow the secondary data connections used by FTP in passive mode. By default this helper is not active. To enable passive‑mode FTP one must load the kernel module and then adjust the connection‑tracking settings so the helper is permitted to run. The key sysctl switch is net.netfilter.nf_conntrack_helper, which should be set to 1; this can be done with sysctl -w net.netfilter.nf_conntrack_helper=1 (lasts until reboot) or by adding the line to /etc/sysctl.conf (permanent solution). After the module is loaded and the sysctl flag is enabled, the firewall rules can reference the FTP helper, for example by adding a firewall rule that uses -m helper --helper ftp or by employing the newer - j CT --helper ftp target in iptables (legacy) or nftables (newer kernel-level firewall interface). And yes, I have done that myself on the Debian-based (and previously Ubuntu Server-based) home server I am using. I know what I am talking about here not just from dry theory, but from hard-won first-hand experience as well.

No, PHP does not expose the FTP errors and messages. The ftp_put() function returns a boolean: true if the upload succeeds, false when it fails. When it returns false you get no other information about why it happened.

The only thing I can tell you is that the error message you are receiving says that they connection to the FTP server worked, the initial directory is correct, the directory you specified exists (or was created), but the actual upload through ftp_put() failed immediately. It returned within a fraction of a second. This tells me that the problem is either a configuration issue on your FTP server, or a configuration issue on the web server.

Here's what.

Test 1: Get another site where you have confirmed that the FTP uploads work. Duplicate that backup profile. In the duplicate backup profile use the FTP connection information from the site which doesn't work. What happens?

Test 2: On the site where you have the problem. Duplicate the backup profile. In the duplicate backup profile use the FTP connection information from the site which you know works. What happens?

If test 1 fails and test 2 succeeds the problem is on your NAS. If test 1 succeeds and test 2 fails the problem is on your host.

Cool! Now you have proven beyond any doubt that the problem IS NOT with the software or the NAS.

Here's why.

The profile that doesn't work on Problem Site works fine on Working Site. This rules out a NAS configuration issue AND a problem with the software (same NAS, same software).

The profile which works on Working Site doesn't work on Problem Site. This tells us that the problem is with this particular host.

I am pretty sure there is a small variation in the configuration of this particular server. This is what our findings point to. Your host should check their config instead of assuming. Is the kernel module loaded? Is the iptables config correct? Do they maybe block connections to your NAS' IP address? This check literally takes under 30 seconds; it's three commands run as root in an SSH shell. If the person you are talking to has no idea, escalate. A level 2 tech will probably quietly curse under their breath and spend a minute checking that stuff anyway.

If you have used Passive Mode in your configuration, yes, it is using what they incorrectly call "passive ports". However, as I said, it looks like they botched the configuration.

As I explained, passive mode FTP opens two connections.

First, a control channel connection is opened from the web server to the FTP server using the configured port (let's say 21 to keep things simple).

The client (PHP) logs into the FTP server using the configured username and password.

We have established everything up to this point works fine.

Then, the client (PHP) sends the PASV command to the FTP server.

The FTP server responds with an IP:port for the data channel.

The client (PHP) opens a new outbound TCP connection to that IP:port (usually a high ephemeral port, e.g. 49152–65535).

First of all, this new TCP connection will be blocked unless the host has configured the nf_conntrack_ftp module and correct nftables rules on your web server as I said before.

This part of the configuration only matters for traffic passing through or originating from that server's own kernel. They ensure the server's own firewall understands FTP connection tracking and allows the second data connection out. It is a necessary but not sufficient condition.

If they are using an upstream firewall (a separate firewall in front of their server), that matters too.

The firewall in front of your server sees raw packets. If it's a stateless firewall (basic ACL-style rules), it has no idea the outbound connection on the ephemeral port is related to the FTP session. It may simply drop it because there's no explicit rule allowing outbound traffic to arbitrary high ports on the remote server.

Even if it's a stateful firewall, it needs its own FTP connection tracking/ALG (Application Layer Gateway) to inspect the FTP control channel, see the PASV response, and dynamically permit that second connection. The nf_conntrack_ftp module on your web server does nothing for the upstream firewall — they are completely separate devices with separate state.

What to actually ask your host:

• Do they allow outbound connections to arbitrary high ephemeral ports (49152–65535) from the web server to the Internet?
• Does their upstream firewall have an FTP ALG (or FTP connection tracking) enabled?
• Alternatively, can they simply allow all outbound TCP from your server? Most passive FTP clients receive a random high port from the remote side, meaning you can't predict it.

In any case, we have proven beyond a shred of doubt that the problem here lies with your host. I am not going to troubleshoot their server configuration. It's not my job; it's their job. They can even reproduce this issue by setting up a simple PHP script on your server trying to connect to your FTP server so they can check exactly how the packets are being dropped.

I will end this reply by saying the following. Everything I talked about is rudimentary Linux systems administration skills. The kind of skills that one cannot simply not possess if they want to run a hosting business. If they can't figure out how they have configured their own servers my advice would be to go to a different host run by people who know what they're doing and who can troubleshoot a rudimentary issue like this without giving you the runaround every step of the way. They may be a slightly more expensive, but your time and sanity cost money, too. I prefer paying a couple of Euro more per month knowing that my host will fix the more convoluted issues within the hour than saving the price of a small pizza every year and wasting dozens of hours of my time in frustration.