Arch Linux User Repository

I'm going to be disowning this package soon. I'm moving away from crashplan and have no interest in maintaining this package, and dealing with usage issues, when I wont be using it.

I'll keep it up to date during the coming months as needed, but if no one else shows up, I plan to disown it at the end of October.

@gadicc, I added some pacman hooks to handle setting/unsetting the immutable flag:

Sets immutable flag after install/upgrade:

[Trigger]
Operation = Upgrade
Operation = Install
Type = Package
Target = crashplan-pro

[Action]
Description = Set immutability of Crashplan Pro upgrade directory
When = PostTransaction
Exec = /usr/bin/bash -c "rm -rf /opt/crashplan/upgrade/*; chattr +i /opt/crashplan/upgrade"`

Unsets immutable flag before upgrade/remove:

[Trigger]
Operation = Upgrade
Operation = Remove
Type = Package
Target = crashplan-pro

[Action]
Description = Undo immutability of Crashplan Pro upgrade directory
When = PreTransaction
Exec = /usr/bin/bash -c "chattr -i /opt/crashplan/upgrade"```

I'd pick it up but I've been honestly considering switching to another service (maybe Backblaze B2). If I decide I'm too lazy to migrate and no one picks it up soon, I'll grab it.

@aaronm-cloudtek Thank you for all your hard work! It's over my head or I'd try to take it on, so until someone else can I updated my manual instructions to make them a bit more clear.

Hi Guys,

Short on time these days and I don't want to make everyone wait for package updates. I've abandoned this package if someone else wants to adopt it.

@achilleas.k Yes it does. The current version is 7.7.0.833, and I installed version 7.4.0.

In fact everything seems to work perfectly. The only problems I ever have are the same well known ones I had on distros that support the normal SysV install, like Ubuntu.

For example, every once in awhile I'll get an email that a machine hasn't backed up for x days, when the local program is actually running fine. This is a known server side problem and CrashPlan support just tells you to issue a "rz,restart" command. A couple of times over the years I've also had the "Can't connect" problem, which is solved by the "restart" command.

Don't get me wrong though, this AUR package does an amazing job of emulating SysV, and there might very well be things it does that I don't use and so am not aware of. But I have 10TB of archives spread across two machines, and everything backs up and restores normally.

By the way, the sysctl.conf "fs.protected_fifos" and "fs.protected_regular" entries are critical for CrashPlan restores. Without them CrashPlan will hang on restoring, but this is another well known CrashPlan problem that has nothing to do with the way it's installed. They're security mitigations that protect the /tmp directory, but cause so many problems that even well known distros like Ubuntu disable them.

@muncrief Does the self updating work for you when you install that way?

Before Manjaro and then Arch I'd always installed CrashPlan manually and made a simple service for it. When I first moved to these distros I gave this AUR package a try, but had various problems and just went back to my simple old manual install and never have any program related problems. I have CrashPlan running right now on two Arch systems and there are no problems with either. So for those who want to try the simple way here it is. We'll assume we've copied the downloaded CrashPlan program to a directory called ~/temp.

First edit sysctl.conf to enable more watches and give CrashPlan access to the /tmp directory:
sudo geany /etc/sysctl.d/99-sysctl.conf
- START ADD -
fs.inotify.max_user_watches=1048576
fs.protected_fifos=0
fs.protected_regular=0
- END ADD -

Now execute this command to load the new sysctl.conf:
sudo sysctl -p /etc/sysctl.d/99-sysctl.conf

Change to the CrashPlan install dir and install, just accept all install defaults:
cd ~/temp
tar zxvf CrashPlanSmb_7.7.0_1525200006770_833_Linux.tgz
cd crashplan-install
chmod a+x install.sh uninstall.sh
sudo ./install.sh

Now stop the CrashPlan engine:
sudo /usr/local/crashplan/bin/CrashPlanEngine stop

Remove the SysV dirs CrashPlan created unless you use them for something else:
sudo rm -r /etc/init.d
sudo rm -r /etc/rc.d

Create the systemd CrashPlan service:
sudo geany /lib/systemd/system/crashplan.service
- START ADD -
[Unit]
Description=CrashPlan backup service engine
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/crashplan/bin/CrashPlanEngine start
ExecStop=/usr/local/crashplan/bin/CrashPlanEngine stop
Restart=always

[Install]
WantedBy=multi-user.target
- END ADD -

Enable and start the CrashPlan service:
sudo systemctl enable crashplan
sudo systemctl start crashplan

And that's it!
From now on you can just control CrashPlan like any other systemd service with enable, start, stop, and restart. CrashPlan will continue to automatically update itself, so you don't need to do anything but check occasionally to make sure everything's okay. Of course if anything goes seriously wrong CrashPlan will email you after a few days to let you know backups aren't working.

Final security note
As I final note I want to make sure everyone is aware of the security implications of setting "fs.protected_fifos=0" and "fs.protected_regular=0" in sysctl.conf.

Awhile ago, I think it was a little over a year ago, there was some kind of malware attack that used the /tmp directory. I don't remember exactly what it was but it was something obscure, but still caused some discussion among the devs about mitigating it, and the above options were added to greatly restrict access to /tmp. However it causes so many problems with so many programs that many distros disable it, including Ubuntu. In the case of CrashPlan, restores won't work normally unless they're disabled.

However, if you want to leave them enabled there is a manual workaround. Before attempting a restore execute "sudo chmod o-t /tmp", and after the restore is complete execute "sudo chmod o+t /tmp" This will clear/set the sticky bit on the /tmp directory which is the root of the compatibility problems.

Same issue here: The service seems to be running, but it's not doing anything and the Desktop app "cannot connect to its background service". Log file (/opt/crashplan/log/service.log.0) shows (not entirely sure if this is the cause or even relevant):

[02.17.20 13:34:27.067 ERROR main                                         ] [main] INFO org.mozilla.jss.CryptoManager - CryptoManager: loading JSS library
[02.17.20 13:34:27.069 ERROR main                                         ] [main] INFO org.mozilla.jss.CryptoManager - CryptoManager: loaded JSS library from java.library.path
[02.17.20 13:34:27.072 ERROR main                                         ] [main] INFO org.mozilla.jss.CryptoManager - CryptoManager: initializing NSS database at NotUsed

I also installed Crashplan (7.7.0) directly from the official archive on a different machine (that has never had Crashplan installed) using their install script and the same error appears in the log when starting and the frontend fails to connect to the background service.

Not sure if any of this helps. Is it possible there's a new dependency or that the application archive is missing something?

Launching CrashPlanDesktop with the Desktop icon I have the message "Code42 cannot connect to its background service" crashplan-pro service is active but I don't think is doing something.

PKGBUILD changes for 7.7.0, until the maintainer is able to get to this (note the url change). Also had to restart the crashplan service afterwards.

pkgver=7.7.0
_pkgtimestamp=1525200006770
_pkgbuild=833

...

source=(https://download.code42.com/installs/agent/cloud/${pkgver}/${_pkgbuild}/install/CrashPlanSmb_${pkgver}_${_pkgtimestamp}_${_pkgbuild}_Linux.tgz

...

sha256sums=('f105feaa533661041194bd1eb154475e220d30db40cf4764a8662b55d14d14bf'

...

Trying to make a package for version 7.7.0

pkgver=7.7.0

_pkgtimestamp=1525200006770

_pkgbuild=833

The service is not starting: /opt/crashplan/bin/CrashPlanService: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory

However the file is there:

[audiolinux@archlinux ~]$ locate libjvm.so

/opt/crashplan/jre/lib/server/libjvm.so

/usr/lib/jvm/java-13-openjdk/lib/server/libjvm.so

/usr/lib/jvm/java-8-openjdk/jre/lib/amd64/server/libjvm.so