Hi,
my version is 2.0.6.1_beta_2021-05-03.
I am confused that drive X: is not offered as source path in my backup configuraton job. But Win10 Explorer does show this drive:
When I type the path manually, a warning appears “path seems not to be there” (translated from german).
Drive X: is a WEBDAV connection to a Nextcloud storage. I want to backup it locally.
Do I have to define this souce in another way?
Onurbi
I’m not 100% sure but I don’t think that’s a supported scenario at the moment. As it stands Duplicati will backup to many cloud providers but as far as I know, isn’t capable of backing up from a cloud provider. It’s a requested feature but not currently implemented.
I see.
What I would like to understand: The Windows drive I defined, is a standard network drive seen from Windows perspective.
What is the fact, which makes this drive different?
It may be due to execution context. For example, if you mapped your WebDAV path under your own user context, and Duplicati is running under a different one (different user, or maybe even LocalSystem if running as a service), then it won’t see the same drive letters you see in Explorer.
On the other side duplicati runs (as admin) as the same user as Explorer. Then it should the same as Explorer.
The Explorer has also successful access, when it runs as admin.
What happens if you exit Duplicati (right-click on tray icon and click Quit), then start Duplicati again? Maybe it needs to be started after you map the drive. (I’m just throwing out ideas…)
It can sort of do it (slowly?) if cloud can be made to look like a local source, which is the problem here.
Services and Redirected Drives from Microsoft says it’s not that simple, but perhaps you can say how Duplicati was installed. Are you on the default of the GUI install and having it start at sign-in of the user? Alternatively if you ran Duplicati.WindowsService.exe and set it to run as a regular user, see the article.
How is Duplicati made to Run as administrator? It’s a little tricky unless one wants to answer a prompt.
Also, unless the Explorer user is an Administrator account, elevating will change to a different account.
Another would be to see what can be done at a Command Prompt that’s known to have access to drive.
Export As Command-line of the GUI job that can’t see that drive can be tried there to see if it sees better.
Happy new year alltogether!
I start it as a task Job with elevated permissions.
Ah, that is the more professional way to start. I’ll read the article and change to the start as a service.
I have two other drives which connects to Samaba servers. I discovered just now, that they don’nt appear in the source data list as well!
This shows me (late!) that in general network drives cannot be backed up.
It’s a pitty, that a needs to create a rather obsolete “rsync” solution under windows to a local drive with robobopy…
It does not help, I tried this already.
Good luck, but the main reason I pointed was its warning:
Each logon session receives its own set of drive letters from A to Z.
which might explain:
Possibly using scripting options for Duplicati in its logon session will get letters.
I don’t have WebDAV, but I tested subst to create a drive Z: for three situations:
C:\Users\Public\Documents\subst>tree /f /a
Folder PATH listing
Volume serial number is E471-3EE4
C:.
+---administrator
| administrator.txt
|
+---administrator_elevated
| administrator_elevated.txt
|
\---standard
standard.txt
Opening Command Prompt of each type could see its own type of Z:, but not the other types,
but this was only true in a given Windows-level logon, using right-click on Start menu to start.
My assumption is that the Command Prompt (Admin) gets a new session with its new token.
Might be considered a different logon session due to either task manager or getting elevation.
Sounds interesting.
Where did you find the sentence? Not in Duplicati.WindowsService.exe.
What is the difference between the situations “administrator” and “administrator_elevated”?
Your subst command was “subst z: C:\Users\Public\Documents\subst”?
I assume you created the files “administrator”, “administrator_elevated” and “standard.txt” in each of the user types.
In the article I’ve been referring you to. Second paragraph. This is how all Windows drive letters work.
“administrator” is Command Prompt in an Administrator account.
“administrator_elevated” is “Command Prompt (Admin)” in same.
No. I made three folders so I could subst to subfolder of drive letter context.
C:\Users\Public\Documents\subst>subst Z: C:\Users\Public\Documents\subst\standard
C:\Users\Public\Documents\subst>dir Z:
Volume in drive Z has no label.
Volume Serial Number is E471-3EE4
Directory of Z:\
01/01/2022 05:37 AM <DIR> .
01/01/2022 05:37 AM <DIR> ..
01/01/2022 05:37 AM 0 standard.txt
1 File(s) 0 bytes
2 Dir(s) 299,386,494,976 bytes free
C:\Users\Public\Documents\subst>
No.The folders and files are all from this Standard acount. They’re just testing what’s visible at Z: drive.
This is about drive letters being non-global, which I think is why Duplicati (as-launched) can’t see yours.
I did make a different subst Z: for each of three contexts. They don’t see each other in other sessions.
I’m just testing the idea that drive letters are not global, and using what Z: points to to track three setups.
Of course, now it’s clear!
Indeed I never wondered about this before!
I’ll reconstruct this in the next days.
Mapped network drives (which a WebDAV folder is considered) only exists in the current users context and cannot be accessed between user accounts. While they behave like a local drive to the user that mapped them, they just don’t exist for other users.
If Duplicati is running as a different or elevated user the X: drive will not exist for that user. If you run Duplicati as the user that mapped the X: drive it should be able to back it up no problem.
To pick on the specifics (although I think the general sentiment on separated drive letters is just right):
I think it also has to be the same logon session, which is why I suggested mapping in Duplicati script.
I have a Command Prompt (Admin) from two different logon sessions, but they don’t share subst Z:.
One has it. The other doesn’t. User is identical per whoami and both look elevated per whoami /priv.
My Session numbers of 1 and 2 are also visible from Process Explorer or (more confusingly) tasklist.
C:\Windows\system32>tasklist /v /fi "IMAGENAME eq cmd.exe" /fi "USERNAME eq Maintenance"
Image Name PID Session Name Session# Mem Usage Status User Name CPU Time Window Title
========================= ======== ================ =========== ============ =============== ================================================== ============ ========================================================================
cmd.exe 24664 2 728 K Unknown HP4\Maintenance 0:00:00 N/A
cmd.exe 5872 Console 1 2,448 K Running HP4\Maintenance 0:00:00 Administrator: Command Prompt - tasklist /v /fi "IMAGENAME eq cmd.exe"
C:\Windows\system32>
Actually, Task Manager as administrator shows this if suitable columns are selected. Here are the two:
How’s it going? If it wasn’t clear before, maybe it’s clear now (and more tools have been demonstrated).
Thanx for the remider!
I started an elevated cmd.exe and ran “net use…” for drive X:.
Result: Duplicati, which uns elevated as well can see X: as well.
The idea to run “net use…” as a before script (Duplicati script) should be a good idea and would solve the issue!
An alternative could be to execute it onve with /persistent:yes. Persistent should also survive a reboot.
Strange remains to me is the fact, that whoami still tells me in the elevated cmd window my user name, not “administrator” as I would expect. I know that change the user to administratror with ALT-L will get not exactly the same permissions as using an elevated cmd. I did not find a good explanation for this.
That’s normal. The way UAC works is the administrative power is not included in your security token by default. This makes your account behave like a standard user one. When you elevate, you are given a new security token that now includes administrative power (for that elevated application, and any sub processes).
The username itself is the same in either case, assuming the user is a member of the administrators group. (You obviously can’t elevate a standard user account and you’d have to supply a different username at the time of elevation.)
Glad the issue has been identified!
Oh yes, I remember this far back in my mind!
Now I have several options to include network drives under Windows,
I every case thank you alltogether for your valuable hints!