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?
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?
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.
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…
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.
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.
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”}
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.
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…
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.
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.
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.