[Warning-Duplicati.Library.Main.Operation.Backup.FileEnumerationProcess-FileAccessError]

Support
#1

Just started with Duplicati on Ubuntu and unfortunately having lots of problems. The biggest problem is that Duplicati is not stable with a cifs mount. Getting errors like these during backups:

[Warning-Duplicati.Library.Main.Operation.Backup.FileEnumerationProcess-FileAccessError]: Error reported while accessing file: /xxx/xxx/xxx/xxx/

Saw a topic which suggested to use " cache=none" as a mount option but that does not solve the problem. Also saw a suggestion to use NFS. Because of UID differences I can’t use NFS (and no, I won’t install Kerberos just for NFS).

Tried beta and Canary but both versions have this error. Strange thing is that it’s a different file every time and also the number of errors is different every time.

Does anyone have a workaround or solution for this (mono?) problem or is it better that I search for an alternative product?

FileAccessError while processing files
#2

Welcome to the forum!

Just to be clear, it sounds like you are trying to back up a CIFS mount, as opposed to storing the backups in a CIFS mount. Is that correct? (In general Duplicati works best when installed directly on the machine that has the data you wish to back up. It’s ability to back up files on remote machines is a bit limited.)

Is Duplicati running as root or as a non-root user?

#3

Hi.

Duplicati runs in a Docker container (running as root) on a Intel Nuc. I backup from a CIFS mount to OneDrive. The CIFS mount is connected to a Synology. Unfortunately I can’t run the Docker container on my Synology (215j has no Docker option) or without Docker as Synology 7.0 does not permit root programs to be installed anymore. So I need to get it running on my Intel Nuc.

To be clear: it’s backuping 180Gb without problems. It’s only some smaller files which are causing most of the errors. If you need more info let me know.

#4

Wow, I’ll have to keep that in mind when I think about upgrading. I’m still on DSM 6.x.

When Duplicati throws some of these file access errors, do you see corresponding errors on the Synology side? And if so what do they say exactly?

#5

No errors or messages whatsoever on the Synology side. Makes me think it’s more of a mono issue.

#6

Ok interesting. I’m guessing the CIFS mount is handled by the docker host machine, correct? (As opposed to you installing CIFS stuff and doing the mount inside the docker container.)

What OS is the host running? I wonder if the host level OS is showing any errors…

#7

That’s correct. The host machine is running on Ubuntu 20.10. There are some messages in the syslog:

kernel: [137184.939794] SMB2_read: 60 callbacks suppressed
kernel: [137184.939795] CIFS VFS: Send error in read = -4

Google din’t reveal much about these messages.

#8

I found this thread: issues with CIFS on Ubuntu 20 mounting Windows 2019 — Linux CIFS Development

Seems similar but instead of Synology it’s Windows Server 2019. I don’t know if it’s me, but I have a really hard time following the thread on that web site. I looked through several messages but never saw a resolution. Not sure if I missed it.

#9

I found that one as well. There is no solution in it. Saw someone mention something about mono though.

Really don’t know how to proceed. Are there any debug methods or parameters I could try?

#10

Yeah I saw the reference to mono as well, which was interesting.

Could you try the CIFS mount using SMB3 (or even SMB1, if the NAS still allows it) just as a test?

#11

I was using SMB3 already. Tried SMB2 and tried some other Synology SMB options (locking. lease etc) but all options still give the same backup error.

#12

I’ll try setting up an Ubuntu 20.04 system to see if I can reproduce the problem. But I only have DSM 6.x on my Synology so it won’t be exactly like your setup.

#13

Thanks! This is one of the errors which I got from the Duplicati logging interface:

{“ClassName”:“System.IO.IOException”,“Message”:“Win32 IO returned 997. Path: /path/file.txt”,“Data”:null,“InnerException”:null,“HelpURL”:null,“StackTraceString”:" at System.IO.File.GetAttributes (System.String path) [0x00018] in <254335e8c4aa42e3923a8ba0d5ce8650>:0 \n at Duplicati.Library.Snapshots.SnapshotBase.GetAttributes (System.String localPath) [0x00007] in :0 \n at Duplicati.Library.Utility.Utility+d__21.MoveNext () [0x0029f] in :0 ",“RemoteStackTraceString”:null,“RemoteStackIndex”:0,“ExceptionMethod”:null,“HResult”:-2147023899,“Source”:“mscorlib”}

#14

I am able to reproduce the problem. Ubuntu Server 20.04, CIFS map to NAS, Docker-based Duplicati.

Confirmed that changing the CIFS mapping from SMB3.1 to SMB3 or SMB2 made no difference.

Confirmed that problem doesn’t happen on the Ubuntu host itself using something like tar to read all the files in the CIFS mount. It also doesn’t happen if you use tar inside the docker container. Looks like mono may be the key.

I then tested Duplicati installed directly on Ubuntu and also had the same problem, so docker seems irrelevant.

No change when upgrading from Duplicati 2.0.5.1 to 2.0.5.111.

I’ll do more testing.

Edit - upgrading from mono 6.8.0 (Ubuntu repository) to 6.12.0 (Mono repository) made no difference.

1 Like
#15

I found a very similar problem with another backup application called Restic (link to issue). That product is written using Go (not C# plus mono framework) but it suffered the same issue when trying to back up to a CIFS mounted directory.

The problem seems to be that the Linux kernel sometimes returns EINTR which is kind of a failure but not really. The calling application or framework is supposed to retry the operation.

The Restic team toyed around with updating their application to handle EINTR but then decided to wait for the underlying Go libraries to be improved and properly handle the situation.

So maybe this is actually a bug with mono in that it doesn’t handle EINTR correctly. Or maybe we could work around it in Duplicati somehow. I’m not really sure.

Anyway, after messing with this for several hours I have not yet found a workaround…

#16

Small update: it ran last night without errors or warnings. Also no errors in the syslog. I didn’t change anything so the problem is still there but it shows it doesn’t happen at every backup run.

#17

Interesting. In my testing it was very consistent… hundreds/thousands of CIFS kernel warnings/errors every time I ran a backup. The set of data I was testing has about 50,000 files, and each time I tested I started over as if it was the first backup.

#18

Did a downgrade of my Synology to 6.2.3 but still got the same errors.

Also tried to run Duplicati on my Synology but that is a total disaster (errors all over the place, unworkable slow backups etc). But that is probably something for another topic.

Don’t think there is a solution or workaround available soon so will probably going to try restic or borg.

#19

Yep, I’m on DSM 6.x and was able to reproduce the problem.

Did you install the Mono version from SynoCommunity? The one that was in the official Synology repository is too old.

NFS is one option but I guess it’s too much trouble in your case?

#20

I indeed used Mono from SynoCommunity. Couldn’t find a newer one in other repositories.

Tried NFS but had UID issues (not the same between servers) and don’t want it all point to an admin user or use Kerberos to solve this.