Hm, then I have no idea how duplicati is managing to access my NAS at all. Because as far as I know, the access credentials are indeed stored in the CM (or where else would they be stored?). I can say for sure that I have not entered any access credentials into duplicati (apart from those for the backend).
I don’t know how the mechanism works exactly, but I guess it’s just an in-memory process. You logged on after booting the PC, probably by supplying a password. Windows can try to authenticate to the NAS using these credentials without having to consult the Credential Manager. The Credential Manager is used for all other resources you have to authenticate for (websites, email accounts, shared folders you have to authenticate with another account than your current account).
Yes and no. The way I reported the issue and tested various solutions was wrong because I was looking at the same file on two different shares without noticing it. But (and I think I have not yet reported this part of the story) when I discovered the mistake, the first thing I did was just delete the file (the one that had actually been causing the error all along). This deletion worked fine, which means that I had full access to that file but duplicati nevertheless did not get access.
When I realized that this was equivalent to the original problem, I thought I might aswell check if it gets solved by changing the access rights, this time on the correct file. So I undeleted the file (moved it from the recyle bin back to where it was), changed the permisions using
What happened thereafter is reported here:
In other words, it worked as expected. But what remains unexplained, why I was able to delete that file before changing the access rights while duplicati was not able to even read it.
I realize that this may be very much of an edge case, so that I don’t blame you if you just leave it and attend to more important stuff.
I have no explanation for that. Duplicati just opens the file and attempts to read it. It opens the file in the least intrusive mode possible (non-exclusive read), so it should get access to the file. I am guessing it has something to do with how SAMBA handles the gap from POSIX (Linux) permissions to Windows AD/ACL. Maybe it just caches stuff, so that the delete/undelete fixed the cached permissions?
In any case, the error:
Found 1 files that are missing from the remote storage, please run repair
Is not related to the default.m3lib file.
This error message means that a dlist, dindex or dblock file was missing from the remote storage. As I mentioned elsewhere this is only the file listing (i.e. doing ls or dir on the remote folder) and does not attempt to read or open any file.
I hope this thread isn’t too old to get my note added. If you can point me to a more recent/relevant post that would be great.
Quite simply, I want to run a Duplicati backup from my Ubuntu laptop to my Ubuntu media server. It seems difficult, which makes me think I am missing something, because Dupicati otherwise looks very smooth and easy (thank you).
I have created a folder on the media server and shared it. On my laptop, I can see the folder and read/write with it. It shows as smb://mediaserver/backups.
In the browser GUI for Duplicati, I’m not sure if I should set as the “Storage Type” that it is a local file/folder or use something like SSH. If I select local, then nothing shows up as the share on the server, but if I select SSH, then it doesn’t seem easy to put the smb:// address in.
I’m sure it must be a straightforward task to do this local backup over my LAN. It was certainly easy to make a backup to an attached USB hard drive. After this, my next task is to backup to Amazon S3. But I’m a bit stuck at this LAN backup. Can anyone help? Thanks.