[Bug] Restores top-level files/folders, but sub-folders are all empty ("permission denied")

[Tek4]

Is this a job for the UMASK environment variable?

Current Behavior

CrashPlan restores all files/folders in the original top-level folder, but sub-folders are empty ("permission denied" in logs).

CrashPlan is creating restored folders which itself doesn't have permission to write to!

CrashPlan restores all 1st-level files and folders, but CrashPlan is giving them EXPLICIT READ ONLY permissions so CrashPlan can't restore any files in the empty sub-directories. It appears CrashPlan is restoring the Read-only permissions which were INHERITED at the time they were backed-up.

For restoring, the CrashPlan user group permission was changed to R/W, but CrashPlan is restoring folders with EXPLICIT Read-only permission and then can't write files inside any sub-directories. The restored sub-folders do not inherit R/W permission from the top folder.

CrashPlan runs under a group and user on Synology. The group normally has Read-only permission. For restoring, the group was given R/W permission. Thus, the destination top-level folder has inherited "Full Control" R/W permission for the CrashPlan group.

Original file and folder permissions (when backups are made)

Normally, the BackupAgents group has inherited Read access only:

Top-folder permissions for restore location:

For restoring, BackupAgents group has been given inherited Full Control access permitting CrashPlan to write:

Restored file and folder permissions:

CrashPlan is creating restored folders with EXPLICIT Read-only permission, which CrashPlan can then not write to!

Expected Behavior

No response

Steps To Reproduce

No response

Environment

• OS: Synology DSM
• OS version: DSM 7.2.2 Update 3
• CPU: Intel
• Docker version: 20.10.23
• Device model: DS918+
• Browser/OS: FireFox/Win

Container creation

YAML

services:
crashplan-pro:
image: jlesage/crashplan-pro:latest
container_name: crashplan-pro
environment:
USER_ID: 10xx
GROUP_ID: 65xxx
SECURE_CONNECTION: 1
VNC_PASSWORD: xxxxxxxx
CRASHPLAN_SRV_MAX_MEM: 4096M
CRASHPLAN_SERVER_ADDRESS: SMB
ports:
- "5800:5800/tcp"
volumes:
- "/volume1/docker/appdata/crashplan-pro:/config:rw"
- "/volume1/Data:/storage/Data:rw"
- "/volume1/Media:/storage/Media:rw"
- "/volume1/web:/storage/web:rw"
restart: unless-stopped

Container log

╭――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╮
    │                                                                      │
    │ Application:           CrashPlan                                     │
    │ Application Version:   11.5.0                                        │
    │ Docker Image Version:  25.02.1                                       │
    │ Docker Image Platform: linux/amd64                                   │
    │                                                                      │
    ╰――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╯

Container inspect

Anything else?

No response

[Tek4]

Work-around:

The only work-around I've found is to run CrashPlan as root (USER_ID: 0 and GROUP_ID: 0) during a restore. Doing so permits all files and folders to be restored. Running CrashPlan as an administrator did not work. Setting the UMASK environment variable did not work.

After restore, CrashPlan created explicit permissions on every file and folder that look like this:

Note, even administrators aren't given write permission! Only with CrashPlan running as root can it restore content inside of folders!

Of course, CrashPlan needs to be stopped, Cleaned, and rebuilt with the proper permissions after restoring so it is not left running as root.

After restore, it's fairly straight-forward to replace all permissions—at least for content under a single parent with one set of permissions. It would be much more complex to fix-up a wide array of folders with differing permissions.

I'm not clear if CrashPlan can restore original file permissions. It appears it cannot. That sure would be a big issue on a system with a wide number of users and groups.

This issue has vastly changed my impressions of CrashPlan being a great solution for recovery. It is very useful to me to have a last-resort backup, and CrashPlan is a good value for that. I can deal with rebuilding the container as 'root'. No big deal. But I think having a "Synology compatible" backup that can also restore the file permissions I'm using is not something CrashPlan is providing, and I'm going to have to give this some thought.

I would close this issue, but I'd like to hear feedback and comments.