Arch Linux User Repository

Direct download links page: https://support.crashplan.com/hc/en-us/articles/8717685436173#Direct_download_links

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

Unless my calculations are way off... it'd be ~$35/mo to maintain 7T of backup and ~$70 to restore that full 7T.

I think Amazon recently announced a much, much cheaper super deep glacier that has a low per month resting cost, but I didn't see how much it was to restore.

I assume fryfrog and butler360 are addressing me, and thank you for your responses.

I wasn't aware how far CrashPlan had fallen, but if it's that bad I guess I'll have to try and make sure I recover whatever I may need and switch to something else. However I did do a gigantic 3TB restore about 6 months ago, and got back everything but 8GB successfully. I was a bit surprised that the problem was checksum errors on the lost files though.

In any case, the problem is that I have 7TB of data that must be continuously backed up, and I don't know of any other company that can do that economically on Linux. I looked at BackBlaze sometime ago, and again just now, but while their backup prices are only a bit high (~ $35 for 7TB as far as I can tell), their restore prices are actually separate, and astronomical. In fact I think they encroach upon being absolutely predatory. I mean seriously, I didn't even know companies did that, but at least according to the charts BackBlaze provides they're less predatory than others.

So I welcome suggestions for any and all viable alternatives. But if I can't find any I'll just have to turn the sticky bit off and on for now, and hope that, if the community can't find a solution, CrashPlan will fix it sometime in the future.

I'm with @butler360, I've migrated away from Crashplan too. I'm using Backblaze's B2 for storage, which has been fine so far. I use Duplicity, but it seems unmaintained and I'd look at other software first.

Honestly I'd just find another way to do your backups. Crashplan was pretty decent for a number of years, but they've actually 100% lost all of my data on their end before and since transitioning to the SMB plan it's been getting worse and worse.

By the way, I forgot to mention that I have the same identical problem on both of my computer systems, and reinstalled my main system from scratch just to make sure there wasn't something installation specific about the problem.

CrashPlan also acknowledges that others, even those with supported systems, are experiencing the same problem. However they claim a temporary workaround is to issue a "pause,restart" command in the CrashPlan app. However I tried this and all the ways I could think of to stop and restart CrashPlan and it didn't change anything. The sticky bit has to be removed or restore won't work.

It appears that something broke CrashPlan's restore function in version 6.9.2. I've been using CrashPlan on Linux for years and this is the first time I've encountered this specific problem.

I first noticed it about 3 weeks ago. When I tried to restore some files CrashPlan would get stuck on "Preparing files ...". It would stay there forever, and didn't notice anything was wrong.

After some debugging and analyzing of CrashPlan's logs I found there's a permissions problem with the /tmp directory. CrashPlan creates two pipes there when restoring - "restore-pipe-xxx-request" and "restore-pipe-xxx-response". However when the sticky bit is set on /tmp, as it should be, CrashPlan can no longer properly access these files. I confirmed the issue by simply removing the sticky bit with "sudo chmod o-t /tmp", and restore works. But if I once again set it with "sudo chmod o+t /tmp" restore fails again. And by the way, even forcing read/write permissions on the files doesn't help, the sticky bit has to be removed.

So since the sticky bit will only let the same user that created a file modify it I can only assume that somehow, somewhere, the apparent user is changing during the restore process.

By the way I contacted CrashPlan about this and as soon as they saw the Arch platform in the logs I sent them they absolved themselves of all responsibility and said the only solution was to switch to Ubuntu or Redhat or some other derivative abomination they officially support, so the community is on its own with this one. I mean my goodness, I'm using Manjaro and many in the Arch community think even that is an abomination :)

So I'm kind of stuck now. I don't see any evidence that the user is changing during the restore process, but I'm just a lowly embedded systems designer, not a Linux Guru. So hopefully someone out there with more knowledge than I can fix this.

@SmashedSqwurl this is awesome, thank you!! sorry, had notifications turned off :/

I had a similar issue with the /opt/crashplan/upgrade folder filling up the entire hard drive with downloads for 827. The new version is available via the Crashplan website. Modified the above PKGBUILD with the new version and I'm not seeing any issues. They just had to do this around the holidays didn't they. If you can't wait, this should work: (Only items changed are _pkgtimestamp, _pkgbuild, pkgrel, and sha256sum for download)

# Maintainer: Aaron Miller <aaronm [at] cldtk [dot] com> Contributor: Anthony Boccia <aboccia [at] boccia [dot] me> Contributor: Griffin Smith <wildgriffin [at] gmail [dot] com> Contributor: Bill Durr 
# <billyburly [at] gmail [dot] com>
pkgname=crashplan-pro
_pkgname=crashplan
pkgver=6.9.0
_pkgtimestamp=1525200006690
_pkgbuild=827
pkgrel=2
pkgdesc="An business online/offsite backup solution"
url="http://www.crashplan.com/business"
arch=('x86_64')
license=('custom')
depends=('bash' 'java-runtime-headless=8' 'alsa-lib' 'gconf' 'gtk3' 'libxss')
makedepends=('cpio')
conflicts=('crashplan')
install=crashplan-pro.install
source=(https://www.crashplanpro.com/client/installers/CrashPlanSmb_${pkgver}_${_pkgtimestamp}_${_pkgbuild}_Linux.tgz
        crashplan-pro
        crashplan-pro.service)
sha256sums=('3b6be8fbee83d25af0285b284c099efed7463fb9e7473af6c96662d8637fa5d2'
            'b306d7da0dd41341512ce80ddcfb21bff8a9bb73ab5018696e69d08b89f7f1b6'
            'fd4c80dbd2ea3dcfc9966832a599f1bb310f705f813474d1900c1867ea55155c')

build() {
  cd $srcdir/crashplan-install

  echo ""
  echo "You must review and agree to the EULA before using CrashPlan PRO."
  echo "You can do so at:"
  echo "  - https://support.code42.com/Terms_and_conditions/Legal_terms_and_conditions/CrashPlan_for_Small_Business_EULA"
  echo ""

  echo "" > install.vars
  echo "JAVACOMMON=`which java`" >> install.vars
  echo "APP_BASENAME=CrashPlan" >> install.vars
  echo "TARGETDIR=/opt/$_pkgname" >> install.vars
  echo "BINSDIR=" >> install.vars
  echo "MANIFESTDIR=/opt/$_pkgname/manifest" >> install.vars
  echo "INITDIR=" >> install.vars
  echo "RUNLVLDIR=" >> install.vars
  NOW=`date +%Y%m%d`
  echo "INSTALLDATE=$NOW" >> install.vars

  sed -imod 's|\. $TARGETDIR/bin/run\.conf|:|' scripts/CrashPlanEngine
  sed -imod "s|Exec=.*|Exec=/opt/$_pkgname/bin/CrashPlanDesktop|" scripts/CrashPlan.desktop
  sed -imod "s|Icon=.*|Icon=/opt/$_pkgname/bin/icon_app.png|" scripts/CrashPlan.desktop
  sed -imod "s|Categories=.*|Categories=System;|" scripts/CrashPlan.desktop
}

package() {
  mkdir -p $pkgdir/opt/$_pkgname
  cd $pkgdir/opt/$_pkgname

  cat $srcdir/crashplan-install/CrashPlanSmb_$pkgver.cpi | gzip -d -c - | cpio -i --no-preserve-owner

  chmod 777 log
  chmod 775 electron/crashplan

  mv app.asar electron/resources

  sed -i "s|<backupConfig>|<backupConfig>\n\t\t\t<manifestPath>/opt/$_pkgname/manifest</manifestPath>|g" conf/default.service.xml

  mkdir -p $pkgdir/usr/bin
  ln -s "/opt/$_pkgname/bin/CrashPlanDesktop" $pkgdir/usr/bin/CrashPlanDesktop

  # Fix for encoding troubles (CrashPlan ticket 178827)
  # Make sure the daemon is running using the same localization as
  # the (installing) user
  echo "" >> $srcdir/crashplan-install/scripts/run.conf
  echo "LC_ALL=$LANG" >> $srcdir/crashplan-install/scripts/run.conf

  # Prevent crashplan from restarting itself repeatedly..
  echo '#!/bin/sh' > bin/restartLinux.sh
  echo 'exit' >> bin/restartLinux.sh

  install -D -m 644 $srcdir/crashplan-install/install.vars install.vars
  install -D -m 755 $srcdir/crashplan-install/scripts/CrashPlanDesktop bin/CrashPlanDesktop
  install -D -m 644 $srcdir/crashplan-install/scripts/run.conf bin/run.conf
  install -D -m 755 $srcdir/crashplan-install/scripts/CrashPlanEngine bin/CrashPlanEngine
  install -D -m 755 $srcdir/crashplan-install/scripts/CrashPlan.desktop $pkgdir/usr/share/applications/crashplan.desktop

  # rc.d daemon
  install -D -m 755 $srcdir/crashplan-pro $pkgdir/etc/rc.d/crashplan-pro
  # systemd unit
  install -D -m 644 $srcdir/crashplan-pro.service $pkgdir/usr/lib/systemd/system/crashplan-pro.service
}

post_install() {
  INOTIFY_WATCHES=$(cat /proc/sys/fs/inotify/max_user_watches)
  if [[ $INOTIFY_WATCHES -le 8192 ]]; then
    echo ""
    echo "Your Linux system is currently configured to watch $INOTIFY_WATCHES files in real time."
    echo "CrashPlan recommends using a larger value; see the the arch wiki for details:"
    echo "  - https://wiki.archlinux.org/index.php/CrashPlan#Real_time_protection"
    echo ""
  fi
}

Par for the course with code42... pkgbuild needs to be updated 820->827 and sigs updated (makepkg -g) only to wait for 6.9.1 to drop and do it all over again. Too bad the app wont update itself, or at least let us disable updates. Keep up the good work, and thank you maintainer!!

If you find a solution and become attached to it, the solution may become your next problem.