Arch Linux User Repository

@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"```

Just to expand on the information @MrFlacko reported, the restore problem with CrashPlan is indeed caused by kernel hardening features introduced in kernel 4.19+, and set automatically by Systemd 421+. After reading @MrFlacko's post I was able to find out more information about it in various places, and there's a brief article from January describing the changes in Phoronix at "https://www.phoronix.com/scan.php?page=news_item&px=Systemd-241-Linux-419-Sysctl."

Specifically, they involve the "fs.protected_fifos" and "fs.protected_regular" sysctl options, which alter who can and cannot access files in the tmp directory.

To verify the problem I installed Ubuntu 18.04 in a VM, a CrashPlan supported OS where restore works correctly, and discovered these options appear to have been completely removed from the Ubuntu kernel.

So if you want to enable seamless CrashPlan restore in Arch and it's derivatives, the procedure is quite simple. However this is a decision everyone must make with care as it does have security implications. But in this case I decided the danger was not severe enough in my usage scenerio, and enabled restore as follows:

Edit or add the file "/etc/sysctl.d/99-sysctl.conf" and add:

# For CrashPlan watches, and restore enable
fs.inotify.max_user_watches=1048576
fs.protected_fifos=0
fs.protected_regular=0

After this execute "sudo sysctl -p /etc/sysctl.d/99-sysctl.conf" or simply reboot.

Note that the "fs.inotify.max_user_watches" option doesn't have anything to do with the restore issue. However it's recommended by CrashPlan to overcome the default real-time file watching limit imposed by the inotify API, which can result in some files not being backed up, and sign in problems after the screen is locked.

After adding these sysctl options I once again have a fully functioning, reliable, and stable CrashPlan installation on two computers running Manjaro.

Just installed this using yay

Failed the first tome, but just ran it again and it worked.

I backed up the files nicely, then went to try and restore and It was stuck on "Preparing Files..."

I looked on the Arch Wiki at Crashplan and there is a fix for restoring the files.

$ sudo su

sysctl fs.protected_fifos=0

mkdir <Output Dir>

CrashPlanDesktop

Then you restore the file to that location.

You need to run Crashplan as root.

Make sure you start the crasplan-pro.service or it won't connect

check your backups, I've just tried to restore my local crashplan backup after a failed HDD and it failed to restore. so installed Ubuntu as crash-plan don't support Arch Linux and refused to help. the archive seems to as good as dead. I've tried on Ubuntu, Arch and Windows now and all refuse to restore the data.

a side note. when I installed on Ubuntu it installed a whole slew of other programs not listed above via apt. but I wasn't in a place to note them down.

This is the answer from crashplan (in my case did not solve the problem)

"We have recently observed some unexpected behavior that will cause CrashPlan for Small Business restore jobs to become stuck at "Preparing Files" if a backup job is running, and will not resume until the backup job is complete.

Our development team is aware of the issue and is working diligently to engineer a fix. In the interim, we have identified a workaround that will allow restore jobs to continue. To resolve, use the steps below:

Open the CrashPlan app
Open the Code42 Commands window:
    Press Shift + Control + C on Windows
    Press Option + Command + C on macOS
Type: pause, restart
Press Enter. The CrashPlan application will close and then you can re-open it manually."

@blackhole, just tested and I'm having the same issue. As a workaround you can restore files using their web interface. I'll see if I can figure out what the issue with the client is.

Is restore working? I see the message "preparing files..." forever I have deleted cache, but same result.

It appears that the new package does not overwrite the jre directory. The new version of crashplan bundles JDK11, but the previous jre is 1.8.0_144 which causes the error reported by billyburly.

Hasn't been working since the update to 7. Getting the following error:

<JAVA_HOME>/lib/ext exists, extensions mechanism no longer supported; Use -classpath instead. .Error creating JVM: -1

If you're using lots0logs' new parameters, which work great, to prevent you from having to download the tgz file and calculate the sha256sum, use 5fd8166f3cf7242f8ede9fe225e9fcea1817068069f6ebbdcce64de373d4a17c.

pkgver=7.0.0 _pkgtimestamp=1525200006700 _pkgbuild=581