Support

I assume you are trying to upload to a shared folder called WebsitesBackups on your Synology NAS.

First, you need to make sure that you have created a Shared Folder on Synology called WebsitesBackups. Please note that the name of the shared folder is case-sensitive which means that websitesbackups, WebsitesBackups, and WEBSITESBACUPS are three different shared folders.

Then, make sure that the user you are trying to connect with has Read/Write access to that share. You can set that up on the Shared Folder's Permissions page on Synology DSM's interface (Control Panel, Shared Folders, click on the shared folder, Edit, click on the Permissions tab, check the box in the Read/Write column for the user you are using to log in by SFTP, click on the Save button).

A small side note here: I do have a Synology NAS. I am no longer using it as my primary NAS (I have a much more powerful Linux-on-ARM self-managed server since last year), but I do use it to test FTP(S) and SFTP in Akeeba Backup. When you submitted the ticket I checked that it works (it does), and I shared my configuration with you.

Are you sure you are using the exact same configuration on your other, fully working site? I am being literal when I say "exact same": hostname, port, username, password, and directory. Not even one character difference, not even one letter in a different case. If you do, then yes, the problem would be caused by the host's firewall somehow getting in the way. I have never seen that particular issue before, and I would be hard pressed to imagine how the connection works but sending commands over the encrypted channel the host cannot modify wouldn't, but I also can't think of a way it would be anything else.

That said, I am pretty sure that there is a configuration difference. Maybe a different username or directory? That would be far more plausible than the host's firewall somehow allowing the SFTP connection to go through (including the three-way handshake for the key exchange) but not allow the command over an encrypted channel it cannot read or modify to go through.

If you attach a screenshot, only you and me can see it even though this is a public ticket. The only thing publicly visible is the attachment's filename. Nobody except the ticket owner (you) and the support staff (me) can download the attachments in public tickets. If it would make you feel better, you can of course attach screenshots of the SFTP configuration in both the working and the problem site and I can confirm they are identical.

That said, and assuming the configuration is identical, there's not much else I can help with. The only thing I can reasonably help with is my software and its configuration. Anything beyond that is not under my control.

Assuming the configuration is identical, we have eliminated everything I can help with. We have already established that my software works. You have seen it working on a different site on the same host, connecting to the same NAS. Besides, the SFTP upload code hasn't changed in years, which makes it extremely unlikely that a bug of that magnitude would've gone unnoticed for so long. Therefore, we can rule out a software issue.

Having eliminated the software and its configuration, your NAS' configuration, and any kind of IP blocking on your side or network issue on the hosting side (if either was the case the SFTP connection would fail much earlier, with a different error message) the only variable we are left with is the host.

There's the well-known meme "it's always DNS" among IT folk because weird issues do tend to be DNS issues. It's not a DNS issue in this case. If the server could not resolve the IP to your NAS we'd be getting a different error message. Moreover, it's not a firewall issue for the same reason. Do note that using SFTP does help eliminate a firewall issue since it's an encrypted connection over a single TCP/IP port the host cannot interfere with beyond blocking, and the error message you are getting tells us it's not getting blocked. So, those networking issues are also ruled out.

This leaves us with PHP itself, and the server environment it runs in.

I know what you are thinking. It's the same hosting company, and the same PHP version. It is the same hosting company, but it is not the same server (as far as I can tell from what you have told me). It is very much possible that two servers (or virtual machines) managed by the exact same hosting company in the exact same way end up having slightly different configurations or use slightly different library versions. For example, it may be the case that the misbehaving site is on a server / virtual machine with a slightly different libssh2 version, or a slightly differently compiled PHP ssh2 extension.

If you think that sounds crazy, it's actually not. Just a few months ago I noticed that the documentation on this here site was not updating. I eliminated any dumb user issues, networking issues, etc. Another site on the same hosting company using the exact same code to update its own documentation was working fine. Here's the critical information: the documentation was uploaded as a DocBook XML file which was converted to HTML on the server, using PHP's xml extension, which uses the system's libxml2 library. After quite a lot of troubleshooting we established that the problem was a bug in the Operating System's libxml2 package coming from an OS update which was installed on the server running this here site, but not yet installed on the other server that had no problem. After my host contacted their OS provider, they established it was an upstream bug in libxml2 itself causing a segfault in some rare cases which were triggered when I converted my documentation. It took about 10 days to resolve. If I hadn't noticed and reported the issue everybody would have been none the wiser and the issue would have remained unresolved. This is not the first time I run into something like that, and I reasonably expect it will not be the last one either.

So, yeah, I get it, it's two sites on the "same hosting provider". Still, you should contact your host and tell them the exact same software, on the exact same PHP version, trying to connect to the exact same SFTP server works on site A but not site B which are both hosted on the exact same hosting provider. Maybe there's an issue like the one I bumped into with XML processing that they don't and can't know unless someone tells them to look closely.