CP will not recover files properly

[paradoxgrowth]

Current Behavior

Background:
All software is up to date, and I recently reinstalled the application, but the issue persists despite multiple reinstall attempts. Running on a QNAP within container station. It worked great before, a few years back .
Problem
CrashPlan fails to recover files properly. It either gets stuck on "preparing" and then completes without downloading anything, or it downloads only a partial set of files (e.g., 283MB out of 500GB). In some cases, it downloads incorrect data—hundreds of folders with unfamiliar names (see picture)

Expected Behavior

I should be able to select folders from CrashPlan Cloud, specify a destination folder, and have the files correctly recovered to that location.

Steps to Reproduce:

CrashPlan is running in a container within my QNAP TS-677 NAS, using the following setup code:
docker run --restart always -d \
Transfer CrashPlan to the new installation.
Allow CrashPlan to fully sync.
Choose "Recover" and input my custom encryption key.
Select the files to recover and specify the destination using "Save selected files to" -> "Other" -> custom storage location.
Choose "Overwrite" if the file already exists.
Set "Original" for file permissions and click "Go."

Steps To Reproduce

Background: my crash plan installation is running I am running this on container station within my ts-677 qnap NAS. All software is the latest version, in fact few weeks ago I reinstalled, set it up. I have tried to reinstall the application several times with no luck. I don't understand it worked fine in the past

1Transfer CrashPlan to the new installation.
Allow CrashPlan to fully sync.
Choose "Recover" and input my custom encryption key.
Select the files to recover and specify the destination using "Save selected files to" -> "Other" -> custom storage location.
Choose "Overwrite" if the file already exists.
Set "Original" for file permissions and click "Go."

Environment

Docker version

Container creation

docker run --restart always -d
--name=CrashplanPro
-e USER_ID=0
-e GROUP_ID=0
-p 5800:5800
-p 5900:5900
-e TZ=America/New_York
-e CRASHPLAN_SRV_MAX_MEM=5120m
-e CRASHPLAN_SERVER_ADDRESS=SMB
-v /share/CACHEDEV3_DATA/Virtualize/Containers/appdata/crashplan-pro/config:/config:rw
-v /share/CACHEDEV7_DATA:/storage:rw
-v /share/CE_CACHEDEV5_DATA/Boy-09/CP_Archive.01.2014-11.2021:/storage/CP_Archive/01.2014-11.2021:rw
-v /share/CE_CACHEDEV5_DATA/Boy-09/CP_Archive.01.2014-10.2021:/storage/CP_Archive/01.2014-10.2021:rw
-v /share/CACHEDEV6_DATA/Container:/storage/Containers:rw
-v /share/CE_CACHEDEV5_DATA/Boy-09/CP_Archive.12.2021:/storage/CP_Archive/12.2021:rw
jlesage/crashplan-pro

Container log

See picture

Container inspect

No response

Anything else?

No response

[jlesage]

Can you have a look at /config/log/service.log.0 to see if there is anything obvious ?

[sikhness]

I'm also having a similar issue with restoring, but mine involves trying to restore files to a SMB share volume that's mapped into the container. The container has full write access to the share and in-fact, the CrashPlan app is storing its configurations and working directory structure also on a SMB share. However for some reason when I try to restore, the CrashPlan app fails in the logs with a permission denied error even though the permissions are definitely set up to be able to read and write.

[paradoxgrowth]

Hi jlesage,
First thank you so much for creating this container, it has worked like clockwork, and saved me many many times.
Sorry for the delay, I have been trying different things. It appears to work a bit better when I choose to restore the the original location rather than choosing a spot. I see that it does download the correct files rather than hundreds of folders with unfamiliar names. It doesn't always download 100% of the files, but it is getting about 80% at times.

I have located the file you suggested, and I am not really sure what to look for. I searched for an error and did not see any. I would be happy to post the log file if you can confirm that it is safe to do so (i.e. doesn't have my IP address).

Thanks again and thank you for your prompt response.

[paradoxgrowth]

There is clearly something wrong, I noticed today that it was doing routine maintenance while, supposedly downloading. I see in the history that is showing that downloads are failing integrity checks. Looking more closely there are areas where instead of downloading the file, it just has a bunch of files that just say restore.failed-checksum.file name. How can I fix this?