I’m using Duplicati - 2.0.5.1_beta_2020-01-18 on Windows 10 Pro.
Backup runs without errors, however, each file receives the warning “storing empty metadata”. The target drive got the backup.
How can I prevent the warnings?
When are these warnings relevant to consider?
Thank you in advance for response!
Best regards
Roland, Austria/Gernany
Welcome to the forum!
Do you have any info on what is running the WebDAV service? What OS and application?
Thanks
Thank you for responding:
This WebDAV links to a Cloud-Webspace of German Telekom (just folders and files)
::roland
Ok, I don’t think the backend is the issue. This error is only generated when Duplicati fails to read the metadata on the source files. Not really sure what would cause that but yet the file data itself is readable.
It really happens for every single file that gets backed up?
Is the mapped WebDAV drive the destination (probably more typical) or source (which “might” work)?
Does Windows File Explorer right-click-on-source --> Properties --> Security give reasonable output?
Hah, good question. I assumed it was the destination.
I can access the mapped debdav-drive with all files and folders. Duplicati delivers no errors but for EACH file the warning mentioned above.
what I recognize is the following behaviour:
when I open a MS-Word file on webdav-drive: no problem. However, when I open a PDF-file I am prompted for the webdav-Password (although I confirm and mark it with “don’t ask again”) each time when I want to open it (in the same session). Might be that there is a connection to “metadata”. I don’t know the definition of “metadata” in the context of duplicati. The developer of the software, however, should know it - otherwise the error message could not have been written as it is …
Hope that helps.
By the way. I moved from Acronis to Duplicati and I much more content know. I can now backup my virtual drive from Boxcryptor without troubles. Thank you Duplicati.
::roland
Metadata includes things like Windows NTFS permissions for each file. It sound like you can’t get them, which is why I wanted File Explorer test of a sample file. You can try an ordinary file too, e.g. Calculator:
I don’t know how your mapped drive presents its access permissions, but that might be the problem.
–skip-metadata=true option on Options screen Advanced options might avoid the complaints, but try restoring a sample file to see if it still has the timestamp (assuming file dates are important to you…).
EDIT: I don’t need confidential permission info, but want to know that something reasonable is there.
First of all: Thank you for taking so much time to resolve this (minor) issue which is really not a show stopper …!
As you can see above this drive is FAT, not NTFS. I 'm not sure if I could have influence on this. Nevertheless see the properties of 2 typical file in one of the folders:
Hope that helps.
::roland
I don’t know exactly what FAT means here. File Allocation Table comes in many flavors, and the oldest are obsolete. I’m seeing some signs that FAT means FAT16, but I don’t have anything in FAT16. FAT32 works on a USB thumb drive I tested. It picked up a file’s metadata, and below is what it recorded in a block in backup which was created to hold metadata as opposed to maybe-compressed data from file:
{"win-ext:accessrules":"[{\"Rights\":-1,\"ControlType\":0,\"SID\":\"S-1-1-0\",\"Inherited\":false,\"Inheritance\":0,\"Propagation\":0}]","CoreAttributes":"Archive","CoreLastWritetime":"636506053440000000","CoreCreatetime":"636362575590400000"}
The SID is just the well-known SID for Everyone, and File Explorer agrees that Archive attribute is set.
This was one small file, so there were only two blocks in the dblock file. Each one is a file in that zip file. Possibly yours would make only one. If you want to pursue, it’s easy to extract from an unencrypted zip.
Or maybe you can just try --skip-metadata=true per above to see if it works better than a lot of warnings.
Your screenshots aren’t showing anything immediately suspect, but something seemingly went wrong…
is probably the warning from some exception, and further up you can see how SkipMetadata may help.
It seems like I’m having the same issue and I assume it somehow relates to windows network drives and offline files.
Running the backup on the desktop PC (where the files are natively located) runs without any problems. Running the backup with the laptop where I map the files from the desktop PC as a network drive exhibits the warning messages. This seems to be independet from the situation whether the desktop PC is online or offline (then the backup is done with the cached files on the laptop).
Note: Duplicati doesn’t run as a service but under may account
I am also observing the same issue.
My source files are decrypted files in a Cryptomator drive using Dokany.
I also do not see any security tab when opening file properties of source files.
The backups do seem to work without problems. But I do get the metadata error for every single file (tens of thousands of warnings) - resulting in me ignoring warning messages altogether, and that is the issue here.
Would ideally fix the error or at least be able to ignore this specific error.
Any updates or suggestions on this problem some of us seem to have?