CrashPlan Service fails to start

[ceejayemm]

I have installed the latest version of your package in a docker environment located on a Debian 11 host via Portainer. I have done this previously on other Debian based hosts without any problem. In this case the contain installs and runs - sort of. I cannot get the CrashPlan Pro service to start, the Portainer log file simply says:

[CrashPlanEngine] starting...

over and over.

Looking at the service log file (service.log.0) there appears to be recurring Java errors. How can these be fixed to allow the service to start. I have uploaded the service.log.0 file for you to see:

service.log.0.zip

Chris
.

[jlesage]

How did you map /config ? Anything special with the related filesystem on the host?

[ceejayemm]

I configured the /config folder as: /srv/dev-disk-by-label-ArrayFS/dockerdata/crashplanpro/config:/config this folder was empty but after starting the container it contains: tmp # ls -lrt /config total 36 drwxrwsrwx 2 app users 4096 May 7 19:13 var drwxrwsrwx 3 app users 4096 May 7 19:13 repository -rw-rw-rw- 1 app users 33 May 7 19:13 machine-id -rw-r--r-- 1 app users 1 May 7 19:13 cp_version drwxrwsrwx 2 app users 4096 May 7 19:13 cache drwxrwsrwx 2 app users 4096 May 7 19:13 bin drwxr-xr-x 3 app users 4096 May 7 19:13 conf drwxr-xr-x 4 app users 4096 May 7 19:13 xdg drwxrwsrwx 3 app users 4096 May 7 19:13 log /tmp # so it would appear that I have write access to this folder. Chris

…

On Sat, 2022-05-07 at 10:46 -0700, Jocelyn Le Sage wrote: How did you map /config ? Anything special with the related filesystem on the host? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ceejayemm]

Just updated to your latest version and am still getting the same issue.

Chris

[jlesage]

Just for testing purpose, is it working if you don't map /config ?

[ceejayemm]

I tried not mapping /config as you suggested but docker/portainer created its own volume in the docker storage area. This had exactly the same problem as before.

I then created /tmp/config on the file system (outside of docker/portainer and not on my raid array), mapped /config to this location in the container and redeployed the container (nothing else was changed). The result was that the CrashPlanPro container started normally and is now carrying out a test backup.

I wonder if this is because the docker volume storage area used for /config originally is on the same raid array (mapped as /storage) as the data areas I wanted backed. eg

/config was mapped to: /srv/dev-disk-by-label-ArrayFS/dockerdata/crashplanpro/config

/storage was mapped to: /srv/dev-disk-by-label-ArrayFS

so /config was actually stored within /storage - I planned to exclude the /config folder when carrying our backups (not now sure why though).

It seems I need to add some additional, separate non-raid storage to hold the /config data as I am not that keen about leaving full time in /tmp/config.

Thanks

Chris

[jlesage]

Do you know which file system (e.g. ext3) is used by the raid array ? It seems that the file system does not support some operations used by CrashPlan.

[ceejayemm]

All my file systems are formatted to LInux Ext4. Its a RAID-5 array provided via OpenMediaVault originally v5.x and now v6.x. Docker/Portainer is running directly on the NAS with direct access to the file system.

Chris

[ceejayemm]

Hi I tried not mapping /config as you suggested but docker/portainer created its own volume in the docker storage area. This had exactly the same problem as before.   I then created /tmp/config on the file system (outside of docker/portainer and not on my raid array), mapped /config to this in the container to this location and redeployed the container (nothing else was changed).  The result was that the CrashPlanPro container started normally and is now carrying out a test backup.   I wonder if this is because the docker volume storage area used for /config originally is on the same raid array (mapped as /storage) as the data areas I wanted backed. It seems I need to add some additional, separate non-raid storage to hold the /config data as I am not that keen about leaving full time in /tmp/config. Thanks Chris

…

On Mon, 2022-05-16 at 04:16 -0700, Jocelyn Le Sage wrote: Just for testing purpose, is it working if you don't map /config ? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>