Commandline issues

Trying to get some consistent results here and not having any luck.
Running this commandline:

“C:\Program Files\Duplicati 2\Duplicati.CommandLine.exe” test “webdavs://{nextcloud}/remote.php/dav/files/{username}/{username}&auth-password={pw}” --dbpath=“c:##db\FDUBIZQIYI.sqlite” --encryption-module=aes --passphrase="{secret}" --disable-module=console-password-input

yields …some extra unknown files … please run repair.

I copy the commandline above and put in repair instead of test and this comes back:

Listing remote folder …

ErrorID: EmptyRemoteLocation
No filelists found on the remote destination

Color me confused. The ‘test’ command shows some missing files and the ‘repair’ command can’t even find the remote location.

Some other results that may or may not help in the diagnosis:

list-broken-files -->
ErrorID: CannotListOnDatabaseInRepair
Cannot continue because the database is marked as being under repair, but does not have broken files.

list -->
No time or version matched a fileset

I get the same results under canary and the latest beta so clearly it is something I am doing wrong or don’t understand. The gui tool lists the same results.

Also looking for a recommendation for a 3rd party DAV testing tool. The ones I’ve found on line is equivalent to killing a mosquito with a shotgun.

Although in my ‘test’ vs ‘repair’ commandline adventures, I’m not sure what a 3rd party tool would do for me, since one of the duplicati functions finds the files and the other one doesn’t.

Can you verify this? That path doesn’t look valid.

Do you have your backup job configured in the Web UI? Has it ever worked to run that backup job?

Doc (or would you prefer Rod?) I missed a backslash, but yeah, I temporarily moved the databases around to an easier-to-enter directory. And now typing that line, makes me wonder if duplicati depends on the ‘dbpath’ parameter to find its lock file and the duplicati-server.sqlite file. Running in M/S windows always is more complicated!

Thanks for catching that one.

The backup jobs are always configured in the UI. It’s only when I start playing with ‘test’, list-broken-files, etc. that I move out to the command line – it’s just easier to manipulate arguments.

One of the big mysteries to me is how the ‘destination’ test in the GUI connects and even offers to create the directory structure if needed, and yet after populating that created directory with ‘sneaker-net’ files, the backup process (or repair or test or ….) says destination has no files.

If you grab one of the ‘missing’ files listed on the console from the ‘test’ or ‘repair’ options, and take it to the backend, the file is there. I thought for a while it could be a linux permissions issue, but after chmod-ing the whole structure to 777, I’ve eliminated that possibility. I’ve even connected using the webdav ‘explorer’ option in windows (this is what I ended up with to test my webdav destination) and the files are there and writable. I certainly would love to find a command line tool that would simply confirm correct webdav and directory file parameters.

I’ve also discovered that if you give up repairing a db because of thousands of ‘missing’ files (that aren’t really missing), and delete your db and start a re-create, it very happily finds the files and starts the rebuild. Nothing else in the webdav destination has been changed. Only the db has been deleted. Why can duplicati find the files to rebuild, but can’t find them to repair?

I’ve been playing with the live log feature, but haven’t consistently found an order to do things. Do I start the job in the GUI and then immediately flip on live log? Is live log captured in a file somewhere, or is it just to console? Can I set the option and file location in the ‘advanced settings’ boxes? Also, when rebuilding a db, is there a commandline option to grab system event data, so I can capture time and completion percentage?


If you only have trouble once you start messing with command line stuff, then I wonder if you have any % characters in your password (or anywhere else for that matter).

CMD needs these characters doubled up when they are used in a batch file. eg, “test%string” needs to become “test%%string”. (When CMD parses the batch file it will end up converting them back to single %'s.) I know when I first starting messing around with some command line stuff, this held me up for a bit.

I do have a “#” sign in my user password, which the export command function changes to its ASCII value (%23), so I fixed that before running the command. Interestingly enough, there is also a “#” in the passphrase that is left completely alone by the export command action.

Try doubling that % and see if there is any difference.

Edit: wait, what do you mean by “you fixed that before running the command”? The character should be escaped when it is in a URL. # -> %23. If you change it back it won’t work right. Go ahead and double the % sign - it’s needed when runniing the command in a batch file.