Error on backup on a CIFS mount

Getting Help
1

I getting for a backup job (local Linux Mint 20 to Hetzner Storage Box) that is running for years now this error for some files. I mount the storage box via CIFS.

Save(<data/bdf052a6f5>) returned error, retrying after 492.389441ms: Chmod: chmod /media/…/…/t…/data/bd/bdf052a6f5eae54e8df40233a695224d0af9650553b7482a535c494aebc84e16: interrupted system call

I read in the docs that CIFS is not recommended anyway to work around this?

2

it seems that export GODEBUG=asyncpreemptoff=1 and nouser_xattr as mount parameter cured the backup but if I run a check I get

using temporary cache in /tmp/restic-check-cache-242041435
created new cache in /tmp/restic-check-cache-242041435
create exclusive lock for repository
load indexes
check all packs
List(data) returned error, retrying after 552.330144ms: lstat /media/…/…/…/data/07/071f648602ee708809783eb7e107e12edb4d585234256811e587d23200b5a141: interrupted system call
List(data) returned error, retrying after 1.080381816s: lstat /media/…/…/…/data/03/031d76c6a3647c5f982f4ed7c828a2e9ff486c6a7875bf7dc83f8acd14d8091e: interrupted system call
pack 47569b11: does not exist
pack 0e66da75: does not exist
pack c0d949c6: does not exist
pack 34fea36e: does not exist
pack 93f7c3ca: does not exist
pack 6095958e: does not exist
…
check snapshots, trees and blobs
Fatal: repository contains errors

Anything I can do about these packs etc.?

3
  1. Make sure you use a version 0.10.0 or higher
  2. run restic rebuild-index
  3. run the backup(s) again and hope that this heals your repo (this works if all the data that exists in the backups is still available and thus backup’ed again)
1 Like
4

excellent. this worked for me

load indexes
check all packs
check snapshots, trees and blobs
read all data
 [30:40] 100.00%  2362 / 2362 packs

no errors were found

5

restic 0.9.6 was built using Go 1.13 which doesn’t have the “interrupted syscall” problem.

What worries me is how these pack [...] does not exists errors are caused. Either the interrupted syscalls also wrecked the check results (but I’d expect some other errors to be printed) or something generated / left behind invalid indexes (or the syscall just returned wrong success messages?). If the interrupted syscalls are really just random interruptions but return correct data otherwise then there could be a subtle bug somewhere in restic…