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

When building the newest package, I get these messages:

-> Stripping unneeded symbols from binaries and libraries... strip: ./opt/crashplan/nlib/stCJGAJK: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/stCJGAJK[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/st1CnLj6: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/st1CnLj6[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/stekm9Rr: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/stekm9Rr[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/st2vyAZG: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/st2vyAZG[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/stbsy1GX: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/stbsy1GX[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/stZsh7sa: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/stZsh7sa[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/stYZabpn: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/stYZabpn[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/stTh0U6u: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/stTh0U6u[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/stXg5tvl: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/stXg5tvl[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/strOxeas: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/strOxeas[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/stqm97QD: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/stqm97QD[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/stPolXmN: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/stPolXmN[.note.gnu.build-id]: bad value strip: ./opt/crashplan/nlib/st36tEAW: not enough room for program headers, try linking with -N strip:./opt/crashplan/nlib/st36tEAW[.note.gnu.build-id]: bad value

Is this a problem?

pkgver=7.4.0

_pkgtimestamp=1525200006740

_pkgbuild=566

This url is working: https://download.code42.com/installs/agent/7.2.0/1641/install/CrashPlanSmb_7.2.0_1525200006720_1641_Linux.tgz

In the PKGBUILD: https://download.code42.com/installs/agent/${pkgver}/${pkgbuild}/install/CrashPlanSmb${pkgver}${_pkgtimestamp}${_pkgbuild}_Linux.tgz

@ariskou

 -> Downloading CrashPlanSmb_7.2.0_1525200006720_1641_Linux.tgz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404 Not Found

I've posted an updated PKGBUILD for 7.2.0 at: https://pastebin.com/r4PcTRdU

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."