Getting odd metadata errors

joolsr · December 11, 2017, 1:52pm

Using Duplicati version Duplicati - 2.0.2.13_canary_2017-11-22
Pc running Manjaro Linux up to date.

Hi

I recently started getting lots of errors such as the following :-

Failed to process metadata for "/home/julianr/xxxxxx, storing empty metadata
UnixSupport.File+FileAccesException: Unable to access the file “/home/julianr/xxxxx” with method llistxattr, error: ENODATA (61)

The files appear to be backed up ok still, but I got over 64000 errors same as above. All these files are on the same machine (although via a smb mount from a server) that is running Duplicati. The backup is running to an Amazon S3 account.

I’m wondering if it may be related to installing timeshift which I’m using with rsync links to create snapshots of my os?
This is only a guess due to the timing of when the backup issues started and when Timeshift was installed. Uninstalling Timeshift and rebooting hasn’t helped though.

I cant find any info on these errors or if they relate to Timeshift.

If anyone can help please do

JonMikelV · December 11, 2017, 5:51pm

At first glance I’d GUESS you’re right and it’s related to the rsync + hard-link mode of timeshift…but that’s just a guess.

If you create a small test backup pointing to a few of the files that show up in your 64,000 errors do you get the error with that new backup as well? (I’m assuming you will…)

kenkendk · December 12, 2017, 1:34pm

I think we need to suppress that error message in this line:

github.com

duplicati/duplicati/blob/master/thirdparty/UnixSupport/File.cs#L204


      
              return null;

          

          var use_llistxattr = SUPPORTS_LLISTXATTR && !followSymlink;

          

          string[] values;

          var size = use_llistxattr ? Mono.Unix.Native.Syscall.llistxattr(path, out values) : Mono.Unix.Native.Syscall.listxattr(path, out values);

          if (size < 0)

          {

              // In case the underlying filesystem does not support extended attributes,

              // we simply return that there are no attributes

              var err = Syscall.GetLastError();

              if (err == Errno.EOPNOTSUPP || err == Errno.ENODATA)

                  return null;

          

              throw new FileAccesException(path, use_llistxattr ? "llistxattr" : "listxattr");

          }

          

          var dict = new Dictionary<string, byte[]>();

          foreach(var s in values)

          {

              byte[] v;

According to the docs the error means that there is no data, or that the data could not be accessed. If we suppress this error, we risk loosing extended attribute data in the case where the user has no access to it, but I think that risk is worth it to avoid 64k warnings, since the user really cannot access it anyway.

joolsr · December 12, 2017, 1:43pm

Thanks for looking at this.
Do I take it that without the extended attribute data that the backups are ok and can be restored fully without issues?

I’ve removed Timeshift now but still get errors in the log but these aren’t shown at the end of the backup run oddly enough

kenkendk · December 12, 2017, 1:46pm

I always recommend testing a restore, but I do not see any problems related to this, except if you depend on extended attributes to be restored correctly.

From the description of the error, I think it is more likely an issue with the filesystem, rather than Timeshift.