?auth-u automatically added to destination path

Hello,

thank you for releasing this excellent product Duplicati version 2.0.3.3_beta_2018-04-02 on Windows 7 Pro 63 bits SP1, up to date. I’m testing it extensively and I’m planning to use it as my main backup ASAP.

At the moment I’m trying to get rid of an option Duplicati keeps on adding to the destination path : “file://I:\Sauve_TP?auth-u”. I’m configuring through the graphic interface (GUI).
If I specify a username and a password everything works fine. If I don’t specify username and password I get the following warning :
Warnings: [ The supplied option --auth-u is not supported and will be ignored ]

Thanks for your help.

Hello @Pierre92 and welcome to the forum!

Was there ever a username and password, for example from a different storage type that needed those? Changing “Storage Type” sometimes leaves leftovers from the previous type that don’t suit the new type. Clicking “Manually type path” on the Destination screen will show you the storage URL then you can edit.

It sounds like the username and password were only an experiment to understand this problem behavior. Because there have been other reports of “auth-u” (including mine), I also experimented, and because it appeared that the truncated option was consistently a question mark then six characters I suspect a bug:

which starts after the seven characters file:// but goes seven characters too far (if it can) at the ending.

Hello td678, and thanks for your help.

"Was there ever a username and password, for example from a different storage type that needed those? " answer : never.
I’ve modified the destination path manually, Unfortunately I’m not able to test this modification, as I now get another error : "The process can not access the file because it is being used by another process."
The trouble is I’ve not been able to find which processes and which file, as it is not mentionned in the detailed logs. I even tried to find it with sysinternals tools, with no result. So perhaps someone here knows better.

Süss !

Could you please add some context, such as when it happens, what it looks like, and how Duplicati is left? Knowing how you run Duplicati (Windows service, TrayIcon, Server, etc.) would also help know the picture.
When running Sysinternals tools, note you may need “Run as Administrator” to view privileged processes.

This sounds like the sort of issue that may involve a lock file in control_dir_v2 called lock_v2. I’m not sure.

Win7 Tray Icon Crashing went down that path at first, but the solution wound up being a network change… Curiosity-research after that found (if I recall) issues over how to handle localhost, given IPv6 and DNS.

I’m running Duplicati as a Windows service. There are four backup tasks. Three of them are unable to run because of this locked file.

Task 1 : backup to local disk/directory, no authentification required, works fine
Task 2 and 3 : backup to local disk/directory, no authentification required, locked file.
Task 4 : backup to a remote ftp server, authentification required, locked file.
All task reports are send to my mailbox.

Duplicati doesn’t crash. Same thing if I resart the service, or resart my computer. Only one instance of Duplicati is running. I checked as administrator.

When Duplicati runs it creates the file C:\Users\Pierre\AppData\Local\Duplicati\control_dir_v2 which apparently hold a lock.

I think the lock_v2 file isn’t the one bothering you. That prevents multiple servers from starting (including the server built into TrayIcon). The message is also different. Here’s what I get when I try to start another Server:

C:\Program Files\Duplicati 2>Duplicati.Server.exe
Another instance is running, and was notified

C:\Program Files\Duplicati 2>

Your issue sounds like it’s per-backup-job, and all it take is to run one of the problematic jobs by itself, right? Sounds rather obnoxious and also rather unusual, however there was once a theory and fix mentioned here.

I’m not sure if the fix actually happened, but the reference to concurrent_processing branch probably turned into 2.0.3.6 canary initially which eventually stabilized into 2.0.4.2 experimental which is a step to a new beta.

Downgrading Duplicati can be tough due to database changes, however if you keep careful track of backups made during database upgrades (basically take note of times), you can revert to old database and Duplicati. There are some other awkward ways to test 2.0.4.2 if you’d like. I do notice you seem to be running Duplicati in your own account (instead of as SYSTEM) as a Windows service, so maybe you’re OK with custom setups. Better still is if you have another system to test on. Getting different Duplicati on one is possible but awkward.

EDIT: Even though I suspect this is the wrong file, I’ll use it to demonstrate seeng the issue yours might have. First SHARING VIOLATION was second server start, and the second was me manually trying a rename of file. Your file possibly is the job’s database whose path is on the Database option. To limit captured events noise, you could also set Filter --> Drop filtered events and also set filtering only for Result is SHARING VIOLATION.

EDIT2: How did “The process can not access the file because it is being used by another process.” appear? Was there a stack trace below it? If so, what did the trace say? If not, maybe you can turn logging higher for –log-file output (probably at least Information level). That will give an idea of what’s going on at error time…