Restored files visible locally on Unraid but not in Windows SMB share

Support
#1

Hi everyone,

I’ve run into a bit of a strange issue. I recently restored some files to my Unraid server. When I check directly on Unraid (using the built-in file browser or via SSH), I can see all the restored files and folders correctly.

However, when I access the same location through an SMB share that I’ve mapped as a network drive in Windows, the files are not visible. Has anyone encountered a similar situation before? Or does anyone have suggestions on what might be causing this and how to fix it?

#2

Duplicacy restores files with original owner. Unless you specify —ignore-owner flag, in which case field will be owned by the user Duplicacy is running as.

#3

Thanks! Upon review, the original backup files belong to “Root,” but all restored files are owned by “nobody.” Is this expected?

#4

I tried adding this flag to “options”, but for some reason, the restored files still belonged to “nobody” and I still cant see them. My current options is “-ignore-owner -threads 4” @saspus @gchen

#5

It looks your duplicacy is running as nobody, hence
It can only write files as nobody.

#6

the problem seems to be that Duplicacy writes files with rather strict permissions (drwxr–r-- for directories and -rwxrw-rw- for files). I attempted to set the umask for the Duplicacy Docker container to 000 , but it didn’t solve the issue. Is there a way to make Duplicacy write files with more lenient permissions? like drwxrwxrwx. Thanks

#7

You can probably do it by overriding container entry point and setting umask. But it won’t be safe. The better approach is to run duplicacy as a user you want to own the files, not nobody, and use —ignore-owner.

Or run it as a super user that has enough privileges to set ownership and restore data in the original state — which is likely a preferred way to approach it from the usability perspective

#8

Thanks for the help!

So far I’ve tried a few things:

  1. Running as root (PUID/GUID 0): restored folders still always end up as drwxr--r-- (0744) on the Unraid filesystem, even if the original in the backup was drwxrwxrwx (0777). regardless adding -ignore-owner flag or not. I am wondering why this could happen
  2. Umask: I tried setting the UMASK=000 environment variable for the container, but when I docker exec in and run umask, it still shows 0022. Is there a specific trick for your image to get the umask to 000 (or even 0002), or another environment variable I should use since you mentioned overriding the entrypoint might not be safe.

Also this leads to another strange behavior : the resulting permissions are not what I’d expect even from a 0022 umask (getting 0744 instead of 0755 from an original 0777), I’m a bit stuck.

My main goal is just to get Duplicacy to restore directories that were originally 0777 as 0777 again, and files (e.g., 0666 originals) as 0666, so they’re accessible to all users on my server.

Any further ideas based on this?`

#9

Are you restoring the files to their original location? If not, maybe https://forum.duplicacy.com/t/qnap-files-restored-to-a-new-location-are-inaccessible-cli-2-7-2/4490?u=kgorlen is the problem.

#10
  1. That’s not what I observe:
    log 
    % mkdir b
% chmod 777 b
% echo hi > b/hi
% chmod 777 b/hi
% ls -l b
total 8
-rwxrwxrwx  1 user  staff   2 May 14 07:55 a*
drwxrwxrwx  3 user  staff  96 May 14 07:59 b/
-rwxrwxrwx  1 user  staff    3 May 14 07:59 hi*
   
% duplicacy backup
Storage set to /Users/user/Downloads/2
Last backup at revision 2 found
Indexing /Users/user/Downloads/1
Parsing filter file /Users/user/Downloads/1/.duplicacy/filters
Loaded 0 include/exclude pattern(s)
Packed b/hi (3)
Backup for /Users/user/Downloads/1 at revision 3 completed

% rm -rf b
% ls -l
-rwxrwxrwx    1 user  staff      2 May 14 07:55 a*

% duplicacy restore -r 3
Storage set to /Users/user/Downloads/2
Loaded 0 include/exclude pattern(s)
Indexing /Users/user/Downloads/1
Parsing filter file /Users/user/Downloads/1/.duplicacy/filters
Loaded 0 include/exclude pattern(s)
Restoring /Users/user/Downloads/1 to revision 3
Downloaded b/hi (3)
Restored /Users/user/Downloads/1 to revision 3
Total running time: 00:00:01

% ls -lt
total 8
drwxrwxrwx  3 user  staff  96 May 14 07:59 b/
-rwxrwxrwx  1 user  staff   2 May 14 07:55 a*

%duplicacy -h | grep -A1 VERSION |  tail -1
   3.2.4 (BB214B)
  2. I don’t know if the container you are using will be paying attention to umask. As I mentioned above, you might need to override the entrypoint and set the flags before calling original entry point. However, you shall not need to do that, as duplicacy restores files and directory permissions correctly, per above.