Odd Behavior - Folders Missing? (solved)

Running Linux version


  1. Initial backup took about 4 days. After it finished, I went to test a restore, and found a lot of data missing. After some investigation here’s what I found. Observe a sample list of some files from my media center:

drwxrwx--- 2 bigun users 111 Nov 14 2010 A Christmas Story 1983
drwxrwxr-x 3 bigun bigun 66 Sep 21 2017 A Goofy Movie

Duplicati had backed up ‘A Christmas Movie’ but not ‘A Goofy Movie’. I suspect a permission issue, but I ran Duplicati as root, so I would assume there is a setting somewhere that overrides what user I start duplicati-server under.

  1. After testing my permissions theory, I changed ownership and permissions of a few directories to match the other directories that backup up successfully. I then re-ran the backup job, and found that Duplicati never shows a restore point that I ran manually. Maybe it didn’t detect any changes? Unsure.


I went back and attempted to create a backup job, browsed and couldn’t find the directory I had changed. Duplicati can’t even see it! Definitely a permission issue. But duplicati-server was ran as root, so I’m not sure how to fix.

Hi @Bigun, welcome to the forum!

I’m not sure what issue you’re running into, but based on your test videos it seems unlikely to be permissions related (though I could be wrong).

Is it possible you’ve got another type of file, folder, or size filter that might be causing this?

If you could post your backup job (use the job Export -> As commandline feature and remove any personal / password info) we might be about to rule that out.

Additionally, there is a newer beta version available ( that you might find better performing (though I won’t go so far as to say it will fix your issue).

So, I figured it out, kinda…

It all had to do with my setup. The directory I was backing things up through was a mounted samba share. When I pointed things to the actual source in the Linux filesystem, things worked fine. Although Duplicati should have had full read-rights, I understand how Samba would have messed with things.


Disregard all text above

Wrong again. I had swapped backup over to the Samba mount and it actually was able to see more data than the filesystem mountpoint. I had it right to begin with. To prevent any confusion, I unmounted the Samba share, so I’ll have no choice but to backup the correct location.

Here is the commandline export:
mono “/usr/lib/duplicati/Duplicati.CommandLine.exe” backup “ssh://pi.pwnedclips.com:23//mnt/external/?auth-username=BLANK&auth-password=BLANK&ssh-fingerprint=ssh-BLANK” “/mnt/media/Media/” --backup-name=“Media Center Backup” --dbpath="/root/.config/Duplicati/NCDZIJWGSN.sqlite" --encryption-module=“aes” --compression-module=“zip” --dblock-size=“50MB” --passphrase=“BLANK” --keep-versions=“7” --exclude-files-attributes=“hidden,temporary” --disable-module=“console-password-input”

Also updated to Duplicati -

So I did another test.

I added the folder it couldn’t see manually, and it went in with no issue. I ran backup and it still didn’t see the file inside of the folder, but it didn’t complain that the folder didn’t exist either. I have no clue what is going on. Would the filesystem type make any difference?

Here’s another example. Inside of my Linux Steam folder, I have the following.

/mnt/media/Media/Backup/Server/home/bigun/Steam # ls -la
total 12
drwxr-xr-x 8 root root 121 Apr 8 2017 .
drwxr-xr-x 15 bigun users 4096 Nov 1 01:42 ..
drwxr-xr-x 3 root root 78 Oct 19 01:06 appcache
drwxr-xr-x 2 root root 23 Oct 31 01:03 config
drwxr-xr-x 2 root root 4096 Oct 19 01:14 depotcache
drwxr-xr-x 2 root root 4096 Nov 1 01:42 logs
drwxr-xr-x 6 root root 148 Sep 16 01:11 steamapps
drwxr-xr-x 3 root root 30 Apr 8 2017 userdata

But Duplicati can only see the appcache and config folders. They are all exactly the same permission set, and none of them have any spaces or special characters to throw anything off. Going to keep digging.

I may have found the issue, and it’s a very niche issue very specific to my setup. See this post here for more details: ->Failure to recognize half the files in a directory in Linux - Help & Support - sonarr :: forums

The TL;DR:

If you have the following

  1. XFS filesystem
  2. 32 bit OS
  3. Mono installed from packages
  4. Large partition

Then mono needs the D_FILE_OFFSET_BITS=64 option set before compiling. I haven’t confirmed that’s the issue, but it’s awfully coincidental that my system fits that bill exactly and having the exact same issue.


Confirmed, after rebuilding with the new flag, the missing folders and files were displayed.