Restic failing to read rclone mounted Dropbox (xattr errors)

I’m experimenting with using restic running on a VPS to back up a Dropbox share mounted via rclone. The goal is to mount the Dropbox remote, and use the VPS to back up everything on Dropbox to some other storage location like Backblaze B2. The issue I’m having is that one VPS I’m trying works perfectly, while the other fails with xattr errors. Both VPSs are running the same OS, so I’m not sure what’s going on here.

Using an Amazon Lightsail instance, this works as expected. The share can be mounted and read by restic, and the backup goes exactly to plan. The run finishes, the snapshot is created, and all looks to be well.

Using exactly the same Dropbox remote and the same commands, but this time on a Hetzner VPS, the remote mount initially appears to work correctly. I can manually copy files to and from it using the normal filesystem tools, create new files, and so on. Doing an rclone sync or copy directly between remotes also works.

The mount and backup commands are very simple, using no flags at all.

rclone mount dropbox_remote: /path/to/dropbox_mount
restic -p ~/.resticpass --repo /path/to/local_repo/ backup /path/to/dropbox_mount

However, restic on the Hetzner VPS fails with the following error:

error: nodeFromFileInfo /path/to/dropbox_mount/file.name: xattr.list /path/to/dropbox_mount/file.name: input/output error

This error is repeated for every file under the mounted share.

  • The commands used and the rclone remotes are identical on both the Hetzner and Amazon VPS instances.
  • The underlying OS is the same — Ubuntu 24.04 LTS.
  • The restic version is the same — 0.16.4 on both.

The only differences I can see are:

  1. Architecture — Amazon is x86_64, Hetzner is arm64.
  2. rclone version — 1.53.3-DEV on Amazon, 1.60.1-DEV on Hetzner.
  3. fusermount version — 3.10.5 on Amazon, 3.14.0 on Hetzner.

I’m no expert in the lower level details, but these are the most relevant differences I can think of.

I’ve kept the details relatively light here in case I’m missing something obvious, but I can’t work out why identical commands aren’t working identically here. Any help very much appreciated, and say the word if you need any more info.

Please give the latest rclone version a try ( v1.66.0 at the moment ). FUSE mounts created by different rclone versions can behave very differently.

What’s rather weird is that you say that both the Amazon and Hetzner VPS use Ubuntu 24.04, yet they have different rclone versions. Judging from the ubuntu packages at Ubuntu – Details of package rclone in jammy , your Amazon VPS actually runs Ubuntu 22.04 (which would perfectly explain the rclone and fusermount versions).

Ugh, you’re quite right about this, my apologies. Evidently I’m spending too long staring at multiple identical-looking terminal windows!

I have tried the latest rclone on the Hetzner VPS, and it appears to work. The Dropbox share seems to be getting backed up perfectly by restic now. Many thanks for your help.

Out of interest, although I know it’s more of an rclone rather than restic question, will strange interactions between FUSE and rclone just happen from time to time? Is it better to stick to “known good” versions which work the way you want, and test thoroughly before moving to a new version of either?

Every software has bugs from time to time. But new versions also usually fix lots of bugs. The question whether sticking to a “stable” version for a long time, always using the latest version or a combination of both approaches is best has been subject to endless discussions. So I don’t have a good answer here. I prefer to stick to recent software versions, which however can cause an occasional problem.

From a security perspective recent versions are likely more secure (properly backporting all security fixes to older software versions is nearly impossible, and for a lot of software probably doesn’t happen at all). But blindly running the latest software version can cause problems. That has led to curious situations where everyone avoids x.y.0 versions, with the result of some projects just skipping the .0 version…