"storing empty metadata" for mapped WebDAV-drive

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.

image
image
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:
image
image

Hope that helps.

::roland

two more …
and

::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.