FTP upload error

I am getting the bellow message while trying a first test backup to an fpt server:

Failed: The remote server returned an error: (553) File name not allowed.
Details: System.Net.WebException: The remote server returned an error: (553) File name not allowed.
  at Duplicati.Library.Main.BackendManager.WaitForComplete(LocalDatabase db, IDbTransaction transation)
  at Duplicati.Library.Main.Operation.BackupHandler.Run(String[] sources, IFilter filter)
  at Duplicati.Library.Main.Controller.<>c__DisplayClass16_0.<Backup>b__0(BackupResults result)
  at Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Action`1 method)

Can you please help?

That’s odd - Duplicati doesn’t use any unusual characters in any of it’s file names.

I have a few quick questions:

  1. Does the “Test connection” function work on the step 2 (Destination)?
  2. Are you using a custom --backup-name parameter that might contain an unusual character (like one of these… *?>:<)?

This seems to be an error that is generated by your FTP server. Which FTP server do you use? What is the filesystem at the backend? Maybe the uploaded files contain illegal characters or the stored path is too long.

Duplicati uploads 3 types of files:

  • DLIST files
    Naming convention: (generally “duplicati-”)Z.dlist.zipExample: duplicati-20171102T153518Z.dlist.zip
  • DBLOCK files
    Naming convention: (generally "duplicati-"b<32 random hexadecimal digits>.dblock.zip
    Example: duplicati-b8d7d92d80fb7452b97226c1f608e326b.dblock.zip
  • DINDEX files
    Naming convention: (generally "duplicati-"i<32 random hexadecimal digits>.dindex.zip
    Example: duplicati-iec9e2c5ed4ca4926d65df00845f82e94.dindex.zip

When using encryption, “.aes” is added as an additional extension.
Replace zip with 7z if you have specified advanced option --compression-module=7z

Does your FTP server do any logging? Maybe you can find a hint there about what goes wrong.

Welcome to the forum! I edited your post to improve the formating. (Just added ~~~ before and after the output you pasted, please see here for details).

1 Like

@JonMikelV, the “Test connection” is successful. I’m not using any --backup-name parameter.

The FTP server I am using is a Western Digital My Cloud network disk.
The stored path is just ftp/test so I don’t think it’s something weird.
I did the following. I changed the backup’s destination path to the local disk of the server I run Duplicati.
Then I took those files and manually uploaded the through FileZilla to the ftp share in question. It uploaded them with no error.
So it is definitely something wrong with the backup process. I have also tried --ftp-passive flag to chekced

Does the backup run with the “seeded” files in place?

If not, when you run the backup can you try looking at the “Show logs” → Live (tab) → Profiling (selection) Duplicati page to see if it logs what file is being upload before the “553 File name not allowed” error occurs?

Note that it looks like this may be a pre-existing issue with the WD MyCloud FTP server as I found a related (unresolved) bug entry on GitHub:

So it is a known bug over a year now? Any chance someone finds a solution to this?

I haven’t looked at the code but my guess is that Duplicati is using standard FTP commands and that the bug is actually on the Western Digital MyCloud FTP server site.

I don’t have a MyCloud device on which to test, but is there some place you can look at the FTP server version on your device then check with WD to see if they have a newer version available?

Apparently not. It requires access to a WD device to test. I just updated the issue with a suggestion to try the aFTP backend instead.

Does that work for you?

It has the latest firmware.

I tried a test connection after switching to storage type “FTP (Alternative)” and I am getting an error “Failed to Connect: 2 Users (the maximum) are already logged in, sorry”.
No one is connected and when I select plain FTP “Test Connection” work fine…