Package Details: crashplan 4.8.3-1

Git Clone URL: (read-only)
Package Base: crashplan
Description: An online/offsite backup solution
Upstream URL:
Keywords: backup crashplan
Licenses: custom
Submitter: billyburly
Maintainer: georgyo
Last Packager: georgyo
Votes: 136
Popularity: 0.186353
First Submitted: 2011-09-17 03:06
Last Updated: 2017-06-17 12:18

Latest Comments

davebloggt commented on 2017-11-18 12:52

After I set Java 9 as the default runtime, Crashplan failed to start and had high CPU usage.
Does anyone else experience this problem?

Mr.Burns commented on 2017-10-15 21:45

Sweet! It worked!

I can confirm that uninstalling (i.e. -rsn) "crashplan" and installing "crashplan-pro" allows a seamless migration of all settings and configurations. To facilitate this migration one must enable and start the "crashplan-pro" service via systemctl.

As others have mentioned, I also run crashplan-pro on a headless server. X-11 forwarding and "CrashPlanDesktop" allow me to access the gui on a Windows machine through a separate windows application (xming). If only everything worked so well. Thanks for the guidance!

fryfrog commented on 2017-10-12 18:53

@pauper: Yes, but *not* because they get migrated or re-used locally. When I fire up CrashPlan Pro (after stopping and removing CrashPlan), it is a clean slate. I *then* had to log in using the client, at which point it seems to get all the configuration from the CrashPlan servers.

The "problem" for me is that all my CrashPlan servers are headless, so I had to run the client locally (on Mac), copy the data from the .ui_info file from each server one at a time, use it locally on my Mac in the right place *and* do a port forward over SSH. I *also* stopped the daemon running locally on my mac so I could just use the same 4243 port, but you could fiddle that if you want. I'm lazy.

That was the hardest part, getting the client on my workstation to talk to the remote server just to log in.

pauper commented on 2017-10-12 18:35

@fryfrog - are you saying all of your settings from Crashplan Home were migrated successfully?

butler360 commented on 2017-10-11 23:09

You may be right about that @fryfrog, maybe I forgot about logging in. But at any rate it was pretty seamless.

fryfrog commented on 2017-10-11 22:31

@butler360: I'd have a look at your installation, crashplan goes to /opt/crashplan and crashplan-pro goes to /opt/crashplan-pro so it can't/doesn't re-use any configuration.

That said, all I had to do was remove crashplan and install crashplan-pro, then fire up the gui on another computer (pointed at my server) and log in. It picked up the config and is chugging along now.

butler360 commented on 2017-10-11 19:25

Yeah I simply uninstalled crashplan and installed crashplan-pro. I didn't have to log in again, it seemed to pick up everything.

fryfrog commented on 2017-10-11 19:23

I've been wondering how to do this myself. I'd planned on just installing the aur/crashplan-pro software over top of what I already had.

Mr.Burns commented on 2017-10-11 19:20

For anyone who has switched to the Pro (Small Business) version - have you been able to update the version? As per normal, the self-updating feature of CrashPlan does not place nicely within Arch. I've been able to upgrade in the past by manually copying in the updated files. However, I've not had success in upgrading to the Pro (Small Business) version of the software.

Any assistance would be appreciated.

blackhole commented on 2017-08-22 17:47

Yes, I had to switch to PRO, as stated on the website. However, I don't see the old backup, I see it only on browser interface.

Sparticuz commented on 2017-08-22 15:37

blackhole commented on 2017-08-22 15:08

Did you receive the letter about discontinuing Crashplan for Home and offering a switch to Carbonite or Crashplan for small business? If I understand right, for the first option there is not a linux option and for the second one, should I switch to crashplan Pro?

Kanjelman commented on 2017-07-01 20:02

@georgyo Wow, thank worked perfectly!

I'm curious how that problem occurred because I never had to do the systemctl commands with other programs installed through AUR. Anyways, it's working now so all is well. Cheers!

georgyo commented on 2017-06-30 02:18

@Kanjelman Very likely you the systemd unit isn't started

try running these commands in a terminal

sudo systemctl enable crashplan.service
sudo systemctl start crashplan.service

and then launching the crashplan gui though the icon.

Kanjelman commented on 2017-06-30 02:14

Hello all, I'm a total beginner to Linux and I installed crashplan 4.8.3-1 in AUR for the Manjaro xfce operating system. After the download and installation was completed by the built-in package manager, I tried to click on the crashplan icon and nothing happens (it fails to launch). Did I miss a step? Anyone else experience a similar problem? Any help is appreciated, thank you in advance!

vgivanovic commented on 2017-04-23 16:19

After installation, '/etc/init.d/crashplan' contains '#!/sbin/runscript'. 'runscript' is not listed as a dependency, so crashplan fails to start when invoked by '/etc/init.d/crashplan'.

If this not some unintended artifact of my particular installation or system, '/etc/init.d/crashplan' should be fixed, perhaps to use the more common '#! /bin/sh'.

P.S. If I remember correctly -- and I could easily be wrong -- interpreter files should start with '#! [interpreter]' although '#![interpreter'' is parsed correctly almost universally. It's just not strictly standards compliant.

bigjimlefou commented on 2017-04-04 09:45

Thanks @georgyo for the update and adding optional dependecy to webkitgtk.

@altdev, have you tried without? I can assure you that here it doesn't start without. But I have a quiet minimal install with only i3 window manager. I think that it is linked so the usage of SWT browser component in the app.

ultdev commented on 2017-04-03 23:26

@bigjimlefou Why should webkitgtk be added as an optional dependency to this package? The Crashplan GUI works without it installed, and there's no mention of webkitgtk on Crashplan's system requirements page:

bigjimlefou commented on 2017-03-28 07:58

"webkitgtk" should be added to package dependencies.

davebloggt commented on 2017-02-15 13:03

Is there a reason to include the init script for /etc/init.d even though a systemd unit file is included?

ervinshiznit commented on 2016-12-02 00:24

@joshaspinail Thanks! Worked like a charm.

For anybody else reading this the command to switch to 8 is archlinux-java set java-8-openjdk

joshaspinall commented on 2016-12-01 10:37

**Solved** Same issue here @ervinshiznit. @Georgyo, please let me know if I can provide any useful info.

My default Java environment was set to 7, it seems CP requires 8. Switching this over resolved this for me.

ervinshiznit commented on 2016-11-28 08:59

Is anybody else having issues with the crashplan engine not starting? When crashplan.service attempts to start it gives the error message

crashplan.service: Unit entered failed state.
crashplan.service: Failed with result 'start-limit-hit'.

georgyo commented on 2016-11-20 19:09

I have reached out to Code42. Their official response is that do not and will not support any kind of package management.

hexadecagram commented on 2016-11-15 07:06

Has Code42 been contacted about this issue? We hash files for a reason.

georgyo commented on 2016-11-08 18:15

Ok, since crashplan has zero regard for keeping the file consistent, I turned off validation for that file.

roknir commented on 2016-11-08 17:52

I had the same sha256sums issue when just using makepkg (no helpers like yaourt):

$ makepkg -si
==> Making package: crashplan 4.8.0-4 (Tue Nov 8 11:43:28 CST 2016)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Downloading CrashPlan_4.8.0_Linux.tgz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 178 100 178 0 0 1068 0 --:--:-- --:--:-- --:--:-- 1072
100 44.9M 100 44.9M 0 0 7060k 0 0:00:06 0:00:06 --:--:-- 7920k
-> Downloading crashplan...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3138 100 3138 0 0 10862 0 --:--:-- --:--:-- --:--:-- 10895
-> Found crashplan.service
-> Found install.vars
-> Found sysctl-crashplan.conf
==> Validating source files with sha256sums...
CrashPlan_4.8.0_Linux.tgz ... FAILED
crashplan ... Passed
crashplan.service ... Passed
install.vars ... Passed
sysctl-crashplan.conf ... Passed
==> ERROR: One or more files did not pass the validity check!

I see a different sha256sum on CrashPlan_4.8.0_Linux.tgz than Avatar33 though:

$ sha256sum CrashPlan_4.8.0_Linux.tgz
baab20fafae3ecb1615db51bec5ecb12d499824344823e2160945810ba4ff384 CrashPlan_4.8.0_Linux.tgz

fryfrog commented on 2016-11-08 17:41

Looks like they changed the file again, so the package will need an update to the sha256sum in PKGBUILD.

Powersource commented on 2016-11-08 17:07

Sorry, that's what I meant, I removed pacaur's crashplan cache.

fryfrog commented on 2016-11-08 16:42

You need to remove pacaur's cache, since the file has the same stupid name it doesn't re-download it. Just fails it for hash check.

Powersource commented on 2016-11-08 16:41

I removed crashplan's cache dir but I am still getting the validity check complaint. Using pacaur.

georgyo commented on 2016-11-07 13:31

Apastuszak, my guess that the crashplan.service is not running

apastuszak commented on 2016-11-06 23:59

Also having an issue where the app won't start. Gnome Shell on

georgyo commented on 2016-10-31 15:25

The problem here is very annoying. Crashplan creates new builds without updating their version number or download URL.

Some people's package managers cache the downloaded asset and use that for future builds. However they DO NOT delete it if the checksum fails on build. Meaning that they have to manually delete the file after. This is trouble some as each aur helper caches differently. Yaourt does not do this caching, at least by default in my testing.

If you read older comments there are some that say how to clear that cache.

More troubling, is that sometimes crashplan sends out different versions from different mirrors. Or at least it seems that way, I have never seen it myself, but the comments sure make it seem that way.

The only cure all I can do is skip the checksum. Though that is also not ideal, but may be the only option.

Morrvick commented on 2016-10-31 12:40

Looks like the AUR helpers are having an issue with this for some reason. A manual makepkg worked.

MrKMG commented on 2016-10-31 03:24

Also getting an SHA256 error.

storrgie commented on 2016-10-30 01:26

I was able to install without issue, however when I attempt to run CrashPlanDesktop I cannot see anything. The process appears to start then stop. I'm on gnome-shell (xorg), what should I pull to assist in debugging?

Avatar33 commented on 2016-10-29 10:00

I get the same error as OssiL,
The sha256 of CrashPlan_4.8.0_Linux.tgz seems to have changed to: 329d57cd8103bbd8e5cd8ed4232c26bd2b0b875a040e12d5ac13974a9e763cd5

OssiL commented on 2016-10-27 18:35

I get this error while installing with yaourt:
==> Validating source files with sha256sums...
CrashPlan_4.8.0_Linux.tgz ... FAILED
crashplan ... Passed
crashplan.service ... Passed
install.vars ... Passed
sysctl-crashplan.conf ... Passed
==> ERROR: One or more files did not pass the validity check!
==> ERROR: Makepkg was unable to build crashplan.

terminalmage commented on 2016-10-14 22:07

I noticed some errors in the journal, not sure how long these have been around, could be for a while now:

Oct 14 16:34:26 tardis CrashPlanEngine[25260]: /opt/crashplan/bin/CrashPlanEngine:line 111: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8): No such file or directory

Looking at the PKGBUILD, it adds the LC_ALL env var to the EnvironmentFile sourced by the unit file, but it depends on LANG being set to something other than "C". While I have a proper LANG=en_US.UTF-8 in my /etc/locale.conf, I build packages in a chroot using makechrootpkg, and it turns out my chroot had LANG=C in its /etc/locale.conf.

So, just leaving this comment here for people who experience a similar issue, in case it might help them. I was able to fix this by simply setting LANG=en_US.UTF-8 in the chroot's /etc/locale.conf.

georgyo commented on 2016-10-11 19:33

Good catch, fixed to the package to represent that.

Sparticuz commented on 2016-10-11 15:53

Can confirm. requires Java 8.

Here's what I did to get it running (on a headless server):

sudo pacman -S jre8-openjdk-headless
sudo archlinux-java set java-8-openjdk/jre
sudo pacman -R jre7-openjdk-headless
sudo systemctl daemon-reload
sudo systemctl restart crashplan

Removing jre7 is obviously optional.

jschwab commented on 2016-10-11 15:46

I didn't see it in the release notes, but it appears that 4.8.0 requires Java 8.

tmoore commented on 2016-10-02 19:55

FYI.. check your backups.. just realized mine hadn't been working for 3 days because crashplan is trying to upgrade itself again. Still debugging

georgyo commented on 2016-09-22 23:27

It's a crashplan thing, if you can figure out why it creates it, let me know.

The pid inside the file is also wrong, the correct pid is in /opt/crashplan/ It creates that pid in it's working directory by default. It wouldn't be too hard to move to a standard location. I'll test that out in a bit.

Sparticuz commented on 2016-09-22 20:49

Crashplan seems to be putting it's pid into /usr instead of /run. Is that an aur thing or a Crashplan thing?

jasonhansel commented on 2016-08-22 02:29

@timemaster did you manage to create a PKGBUILD that allows CrashPlan auto-update? It might be useful to post it here (or even submit it to the AUR)

georgyo commented on 2016-08-09 00:48

I really can't explain why the checksum is failing for so many people. I still can't reproduce. It keeps failing because its doing the checksum against the bad version cached by your AUR helpers. However, how so people downloaded a bad tar ball is puzzling me.

timemaster commented on 2016-08-09 00:22

probably a permission issue. when using official crashplan install script, it install crashplan run as root and can update itself, at least what I think after today installation. I am also tired of this, because for 2 weeks the checksum on the crashplan zip file of this package failed and the current installation did not work as not updated. I

jasonhansel commented on 2016-08-06 18:45

Whenever CrashPlan releases a new version, I get emails saying that my backup hasn't fully completed until I perform the upgrade. While I know that this violates the usual package-management philosophy, I'm wondering if it's possible to have a crashplan package that *enables* automatic update, in order to avoid this issue. Does anyone know how CrashPlan's auto-update feature works, so that I could create such a package?

Anonymous comment on 2016-07-20 22:06

Sorry I guess I should have mentioned I'm using pacaur. I cleared my cache as @tmoorge suggested and it's working now. Thanks!

tmoore commented on 2016-07-20 17:38

You may need to clean out your pacaur cache directory.
rm -rf ~/.cache/pacaur

georgyo commented on 2016-07-20 15:14

It's possible that they are doing A B testing... I can't get the error, I have tried pacaur, yaourt, makepkg, and 10 iterations of clean-chroot-manager. Every single time it downloads the file and passes the checksum.

DrTeeth commented on 2016-07-20 15:03

@trimalchio @georgyo

When trying to update crashplan using pacaur -Syu, I get

==> Validating source files with sha256sums...
CrashPlan_4.7.0_Linux.tgz ... FAILED

However, when I download crasplan from the aur directly and run "makepkg -sri ", it installs with no problems.

georgyo commented on 2016-07-20 12:46

@trimalchio I can't reproduce your error.

Anonymous comment on 2016-07-19 23:53

I'm getting an error trying to update this package:

==> Validating source files with sha256sums...
CrashPlan_4.7.0_Linux.tgz ... FAILED
crashplan ... Passed
crashplan.service ... Passed
install.vars ... Passed
sysctl-crashplan.conf ... Passed
==> ERROR: One or more files did not pass the validity check!
:: failed to verify crashplan integrity

rtieben commented on 2016-07-19 13:44

Thanks! I have those settings.
Testing shows that crashplan sometimes connects, and sometimes keeps hanging on the 'waiting for connection'. Any other solutions/tips? Thanks!

butler360 commented on 2016-07-18 10:57

Seems the URL changed?

The website links and the ultimate download URL is

Validation kept failing until I manually changed the URL to that.

mikep commented on 2016-07-13 20:54

I have been having a problem for the last few days where crashplan keeps downloading a failing update which eventually fills the partition.

According to Code24 support there is a new bugfix download at the normal place, but with the same version number.

tmoore commented on 2016-07-05 14:31

Make sure your /usr/lib/systemd/system/crashplan.service file looks like this:

Description=CrashPlan Backup Engine

ExecStart=/opt/crashplan/bin/CrashPlanEngine start
ExecStop=/opt/crashplan/bin/CrashPlanEngine stop


rtieben commented on 2016-07-05 10:53

Crashplan hangs at 'waiting for connection' after reboot, needs a manually restart.
Wiki suggestion networkmanager-dispatcher-crashplan-systemd no longer exists; doesn't seem to work either.

baldrick commented on 2016-05-19 09:43

Sorry no, I already upgraded manually by changing version in the PKGBUILD.
Mine kept working too, until I restarted the service and then tried to reopen the GUI. That's when it got stuck on the green splash screen stating "Updating".

justin8 commented on 2016-05-17 07:43

Updated the package now for 4.7.0

@baldrick can you capture some logs and/or screenshots? I don't experience that behaviour on my headless or GUI machines, they keep working but have that little automatic update failed message.

blackhole commented on 2016-05-16 17:07

Just compiled 4.7.0 only changing version in the PKGBUILD and all is working fine

baldrick commented on 2016-05-16 16:59

This is broken due to an automatically enforced Crashplan update. That's to say - within the client it keeps trying to trigger an update every hour which fails. If you then exit the GUI and reopen it it hangs on "Updating".

blackhole commented on 2016-05-16 15:42

If not updated to last version 4.7.0, gui will hang

justin8 commented on 2016-05-13 20:16

gtk2 is already an opt depend since it is only for the gui. It tells you this when you install the package.

xorg-fonts-type1 isn't a requirement as far as I can tell. It isn't installed on my laptop and it works without issues

fryfrog commented on 2016-05-13 15:47

A lot of us run Crashplan headless, so GTK2 and xorg-fonts-type1 aren't *requirements*, but they certainly could be optional dependencies.

adambot commented on 2016-05-12 23:51

Also requires GTK2 and xorg-fonts-type1

whstrain commented on 2016-04-29 15:25

I found a bunch of log files under /opt/crashplan/log that people might want to clean out. rm -f upgrade.*.log. Also, the content of the upgrade log file may lend some information about the failing upgrade process.

Thu Apr 28 17:29:23 EDT 2016 : Ensuring the UpgradeUI is not running.
Thu Apr 28 17:29:23 EDT 2016 : UpgradeUI is shut down.
Thu Apr 28 17:29:23 EDT 2016 : JAVACOMMON is set: /usr/bin/java
Thu Apr 28 17:29:23 EDT 2016 : Current Java Version: 1.8
Thu Apr 28 17:29:23 EDT 2016: The Current java is not compatible. Embedding a compatible version.
Thu Apr 28 17:29:23 EDT 2016 : Download JVM from

whstrain commented on 2016-04-29 13:04

The file was approximately 1435813200460_403.jar.
The folder was approximately 1435813200460.#############. I have a feeling the ??? is the epoch time the .jar was expanded but not sure.

justin8 commented on 2016-04-29 12:24

Do you happen to know the name of the file that was left?

There is no file locking like that in Linux, it would remever the pointer on disk and not overwrite it or free the space until the last handle is closed, but it will happily let you delete and replace in-use files

whstrain commented on 2016-04-29 12:10

I must not have been clear. The install scripts removed many (more than 15) of the update folders but left one; and the update source .jar file was left behind. Perhaps the ones left behind were in use at the time and the service should be stopped at the beginning.

justin8 commented on 2016-04-29 05:03

The .sh files in there are fine, they are part of the upstream package installation.

The install scripts will remove the leftover failed update files if they exist.

whstrain commented on 2016-04-28 22:13

Just installed the 4.6.0-7. Many decompressed update folders were removed but one was left, and the update source .jar file was left behind. Also there are now many .sh files in the upgrade folder. I had to chattr -i /opt/crashplan/upgrade/ and rm -rf * at the end. Works as good as ever.

whstrain commented on 2016-04-28 21:38

What build version is in 4.6.0-7? I still show 4.6.0 build 382.

UglyBob commented on 2016-04-28 17:30

Could be, but it restarts like every 30 seconds (repeated over and over) and I don't think I ever get my new files backed up. I see that there is a new version, so I will try to upgrade and see what happens...

tmoore commented on 2016-04-28 14:18

I see the same kill error, but I think it's benign.. It's basically seeing a leftover pid file and tries to kill a non-existing crashplan process before it restarts.

justin8 commented on 2016-04-28 08:48

What version of the package are you running? I haven't had any issues since the last couple updates.

UglyBob commented on 2016-04-28 08:15

Have had soooooo much trouble with Crashplan lately, my latest trouble is that the log is filled with restarts like this:

Apr 28 10:13:02 uglybob systemd[1]: Started CrashPlan Backup Engine.
Apr 28 10:13:28 uglybob CrashPlanEngine[2681]: Stopping CrashPlan Engine ... /opt/crashplan/bin/CrashPlanEngine: line 144: kill: (2612) - No such process
Apr 28 10:13:38 uglybob CrashPlanEngine[2681]: OK
Apr 28 10:13:38 uglybob systemd[1]: crashplan.service: Service hold-off time over, scheduling restart.
Apr 28 10:13:38 uglybob systemd[1]: Stopped CrashPlan Backup Engine.

I also think it doesn't really backup anything due to this... :/

justin8 commented on 2016-04-21 23:45

I was missing the -r in the update cleanup script. It should be fixed now and do it automatically if you have leftover update files

tmoore commented on 2016-04-21 18:19

Just do this before you upgrade

cd /opt/crashplan/upgrade
sudo rm -rf *

Walliski commented on 2016-04-21 13:11

I'm getting this here:

rm: cannot remove '/opt/crashplan/upgrade/1435813200460_382.1459429507147': Is a directory

justin8 commented on 2016-04-21 03:37

4.6.0-6 will remove old failed upgrade files when you install it. Should require no more manual intervention.

justin8 commented on 2016-04-21 02:10

4.6.0-5 is just pushing now, it should correctly set/unset chattr +i on the upgrades folder and stop the stupid thing finally.

4.6.0-4 contains the non-version-bump update that J4913 mentioned on the 18th.

4.6.0-3 should have fixed the updates taking up disk space issue; it sets the updates folder to 000 permissions so their internal upgrade script fails before it can download. That way pacman can remove it when you uninstall still; chattr +i made pacman throw some errors for me, but it seems that is not working, so I'll have to add the chattr +i on upgrades folder

ZimbiX commented on 2016-04-20 19:12

Ah, perfect; thanks, @tmoore. I upgraded not long after my last comment with the upgrade folder empty, and it's already at 3.8GB! Can we get that added in please, along with deleting the contents? =) I wonder how many TBs this bug has filled all up! xP

Edit: Derp, I hadn't updated to 4.6.0-4... I'll report back if it's still broken without using chattr +i

tmoore commented on 2016-04-20 19:00

FWIW, just run this and never worry about upgrades filling up your drive

chattr +i /opt/crashplan/upgrade

blackhole commented on 2016-04-20 17:33

You could look into the code and absolutely disable autoupdate. Arch package should not be updated out of pacman system.

When I have time I can look to this myself. Today I discovered that in another installation hard disk was full!

ZimbiX commented on 2016-04-20 17:25

I just commented at but it's awaiting moderation, so:

> Thanks for documenting this. CrashPlan just killed my server too – Arch Linux with the crashplan package installed from AUR. CrashPlan appears to have been attempting to update itself about every 30 seconds, using 33MB each time.

> Here’s my /opt/crashplan/upgrade directory size and file listing:

> I’ve deleted the contents for now. Investigations continue…

I could have sworn I updated yesterday, but it turns out I have 4.6.0-3. Is this the same issue @blackhole mentioned?

blackhole commented on 2016-04-19 05:26

OK, now is working with 4.6.0-4

justin8 commented on 2016-04-19 01:11

@blackhole what version of the package are you using?

blackhole commented on 2016-04-18 23:53

It is trying to update but fail:
● crashplan.service - CrashPlan Backup Engine
Loaded: loaded (/usr/lib/systemd/system/crashplan.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2016-04-19 01:52:43 CEST; 11s ago
Process: 5922 ExecStop=/opt/crashplan/bin/CrashPlanEngine stop (code=exited, status=0/SUCCESS)
Process: 6038 ExecStart=/opt/crashplan/bin/CrashPlanEngine start (code=exited, status=0/SUCCESS)
Main PID: 6053 (java)
Tasks: 28 (limit: 512)
CGroup: /system.slice/crashplan.service
├─6053 /usr/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx1024m -Dnetworkadd
├─6128 /bin/bash
├─6143 /bin/bash ../../bin/CrashPlanEngine stop
└─6149 sleep 10
lines 1-12/12 (END)

J4913 commented on 2016-04-18 22:27

$ sha256sum CrashPlan_4.6.0_Linux.tgz
bf9ad86835325118d9f5b7964b42cf4a3c4435c40840e5e4655d8ce01fea3933 CrashPlan_4.6.0_Linux.tgz

inanimate commented on 2016-04-07 00:13

For anyone wondering why the launcher doesn't seem to be working, you'll need to `systemctl start crashplan` before it will launch (it merely doesn't error or anything else if the service isn't running)

In other platform versions i.e. windows, launching it will automatically spawn the backend process.

blackhole commented on 2016-03-24 06:57

Ok, I downloaded from repository.

justin8 commented on 2016-03-24 06:46

Remove the file and try it again. I just removed my source and redownloaded and I'm getting the right checksum. Perhaps it silently corrupted while downloading?

Also, make sure you're on the -3 revision of the pkgbuild. the checksum was updated on -2 earlier today.

blackhole commented on 2016-03-24 06:44

Validating source files with sha256sums...
CrashPlan_4.6.0_Linux.tgz ... FAILED
crashplan ... Passed
crashplan.service ... Passed
install.vars ... Passed
sysctl-crashplan.conf ... Passed
==> ERROR: One or more files did not pass the validity check!
==> ERROR: Makepkg was unable to build crashplan.

justin8 commented on 2016-03-24 06:39

What validity check is that? I just re-downloaded the source and it seems fine to me.

If you want to install it from a binary package, it gets built on my repo within a few minutes of changes being pushed to the AUR:

Tbsc commented on 2016-03-24 06:39

Also installed fine on my computer, but won't launch. Just stays at the loading screen indefinitely.

blackhole commented on 2016-03-24 06:36

Just installed fine in one computer.
After few minutes I tried to install to another and I receive an error message about validity check.

justin8 commented on 2016-03-24 02:49

Ok, just pushed 4.6.0-3; it should disable auto-upgrades. It appears to be working for me with upgrades/downgrades/installs/removals and doesn't complain too much.

The first upgrade will show folder permissions differ on the upgrade folder, but the post_upgrade hook will fix them for people upgrading, and new installs should have the auto-upgrades disabled already.

tmoore commented on 2016-03-24 02:38

Yup noticed that when I googled crashplan changelogs :)

justin8 commented on 2016-03-24 02:32

Busy day at work today, but I was going to see how it behaves over the weekend with 000 perms on the upgrade folder. Disabling automatic upgrades would be wonderful, it only causes issues.

FYI I've updated the package to the latest '4.6.0' release. Annoyingly code42 occasionally re-releases the same version number with no change log or anything but silently update things.

tmoore commented on 2016-03-24 02:21

FWIW, I did just that (chattr +i /opt/crashplan/upgrade) and restarted crashplan, and its running fine without trying to write to that folder. Just remember to "-i" it later (or if it keeps working, maybe I'll just wait for AUR to update instead of letting Crashplan doing it itself.

tmoore commented on 2016-03-24 02:15

You could always lock down the perms of /opt/crashplan/upgrade to 000 (chmod 000 /opt/crashplan/upgrade) or run (chattr +i /opt/crashplan/upgrade). That should prevent root from being able to write to it. I don't know the app will behave but it should prevent it from writing.

justin8 commented on 2016-03-23 23:52

Looks like it is still ongoing. My laptop has an almost empty upgrade folder when I turned it on. but there is another folder every minute.. My always on server has 32GB. (Out of a 60GB root SSD that's quite a bit.).

I've lodged a ticket with crashplan to see what they say. I can't see any immediate way to solve it and have had to stop the service for now.

tmoore commented on 2016-03-23 23:37

I think they pulled it now. This was the URL it was trying to download from

Now it's just giving a 404, so the upgrader is cleaning up after itself now.

tmoore commented on 2016-03-23 23:32

In the logs it looks like it never quite completely downloads the upgrade jar, so it tries again the next minute (not cleaning up after itself). Could be something with Code42

[03.23.16 19:30:28.097 INFO MQ-Peer-1 .service.upgrade.DownloadManager] DownloadManager stopped.
[03.23.16 19:30:28.106 INFO 4513_DwldMgr .service.upgrade.DownloadManager] DOWNLOAD:: Transferring patch at /linux/upgrade/1435813200460_382.jar; DownloadManager[patchDir = upgrade, patchFiles = [1435813200460 (2015-07-02T05:00:00:460+0000)], patchProblem = false]
[03.23.16 19:30:28.123 INFO 4513_DwldMgr common.filetransfer.FileTransfer] FT::Client-tid=734889419482483231, guid=4200; START. moduleName=installs, srcPath=/linux/upgrade/1435813200460_382.jar, dstPath=upgrade/1435813200460_382.jar, dataWaitTime=900000, options=[]

20500K .......... .......... .......... .......... .......... 44% 15.5M 2s
20550K .......... .......... .......... .......... .......... 44% 9.95M 2s
20600K .......... .......... ...

tmoore commented on 2016-03-23 23:28

Same issue here.. Just checked.. Started with this dir
drwxr-xr-x 4 root root 4.0K Mar 23 19:03 1435813200460_382.1458774204644/

which is about 50mb, and has been creating new directories every minute since then, each around 50mb or so.

It's probably trying to upgrade itself and failing. I'll try to see if it's the update loop again.

J4913 commented on 2016-03-23 23:14

I just noticed crashplan had filled up my root drive (/opt/crashplan/upgrade was 19GiB). I fixed it by uninstalling, removing the directory, and installing again. Any ideas why this might have happened?

Edit: I guess it's the same issue as others are seeing - when stuck in the update loop it doesn't remove update files or something.

justin8 commented on 2016-03-15 04:36

@tmoore @jobski That's odd. The pkgbuild only modifies the restart script to use systemd calls instead of init.d, the rest is exactly as is upstream.

I just upgraded crashplan on my laptop before I pushed the change to here and it worked fine, no conflicts, restarted fine, backups fine. Odd. I'll see if it fails when I update my other systems in a few days.

tmoore commented on 2016-03-15 04:15

Yea.. I had to edit the script.. It had a loop in there where it was sourcing, which in turn sourced Very weird.. I'll have to pull down the master copy and see if that's how Code42 built it.

jobski commented on 2016-03-14 23:33

Thanks for the update. My crashplan service kept failing to upgrade by itself and thus, failed to backup. Hopefully it returns to normal now.

justin8 commented on 2016-03-10 22:39

@tmoore @kaqualls the optdepends already says to install gtk2 and java-runtime for the Crashplan GUI

justin8 commented on 2016-03-10 22:38

If the app lets you change it (i.e. it doesn't reset it automatically) the package here won't reset your 'my.service.xml' file.

I don't know if they like you changing the path. I just bind mounted the actual path I wanted to /opt/crashplan/backupArchive in /etc/fstab:

/storage/server-files/crashplan /opt/crashplan none bind 0 0

tmoore commented on 2016-03-05 02:42

Nevermind, I got it working with java8 just fine.. seems that I ran it as root once and it likes to explode those cairo jars in /tmp/.cpswt. So when I tried to run it as myself it couldn't cleanup. All good with OpenJDK 1.8.0_74

justin8 commented on 2016-03-05 02:38

I'll update the optdepends when I get a chance, it needs regular java, the set stuff and another library I forget if you want the GUI as well.

kaqualls commented on 2016-03-05 02:34

I just had a similar problem loading a swt library when opening the GUI. I think I fixed it by installing java-runtime instead of java-runtime-headless.

tmoore commented on 2016-03-05 02:27

No it's fine.. I don't think it's java 7.. I'm getting these kinda errors
Can't load library: /tmp/.cpswt/

It's not unpacking properly on my system.. Could be my configuration.. I'll dig further
NOTE: this is just the CrashPlanDesktop app. The service is running fine.

justin8 commented on 2016-03-05 02:17

I've been using openjdk8 since release to the repos and had no problems. I'm pretty sure they also recommend Sun JDK as well. The package dependency is just on headless java, not a specific version, I'll change that if anyone has a problem with a java version

tmoore commented on 2016-03-05 02:14

FYI.. does this require Java7? Their website says jdk7 only. I'm having some issues running it under openjdk8.

justin8 commented on 2015-12-14 04:43

@jdelisle good catch. I'll add that to the package.

@djhaines isn't that just basic x11 forwarding? I'm not sure if that really belongs on the crashplan archwiki page. Although port forwarding is also pretty simple, the way described there already is from their official documentation on running a headless linux server.

jdelisle commented on 2015-12-11 16:38

I've made a change that seems to have helped me with upgrades and the errors like:

Dec 04 02:03:46 spider CrashPlanEngine[4341]: Stopping CrashPlan Engine ... /opt/crashplan/bin/CrashPlanEngine: line 144: kill: (3940) - No such process

To fix this, I adjusted /opt/crashplan/bin/ as follows:

#$ENGINE_SCRIPT stop >> $logFile 2>&1
systemctl stop crashplan >> $logFile 2>&1


#$ENGINE_SCRIPT start >> $logFile 2>&1
systemctl start crashplan >> $logFile 2>&1

It's been running several days now, and I have success messages in the upgrade logs indicating it upgraded itself from 4.4.1 to 4.5.0 without issue.

Keep in mind this won't address memory issues some users experience with Crashplan. If you find "OutOfMemory" messages in your logs, you need to adjust your /opt/crashplan/bin/run.conf file to allow Crashplan to use more memory. Look at the first line of run.conf (which configures SRV_JAVA_OPTS) and change -Xmx to a larger value. I use '-Xmx6000m' for my 15TB backup, and so far so good.

Hope this can help someone else.

dhaines commented on 2015-12-10 03:00

I've added a bit on the wiki about using CrashPlan headlessly. Essentially, just enable X11Forwarding on the headless box and ssh -Y (or -X) to the server and run CrashPlanDesktop remotely.

justin8 commented on 2015-12-09 22:58

It often is as simple as changing the version and running updpkgsums, crashplan is pretty stable.

I've changed it to restart=always. But often it will fail when it runs out of memory it will fail.

I can't do much about the updates. The normal way to disable them with this sort of package that isn't really designed to run like a normal linux app (i.e. updated via a package manager) is to make sure it doesn't have permissions to do so. But crashplan needs to run as root if you want to backup system files, so that won't really work. It appears lots of people have complained for a long time about disabling the auto-updates, but there doesn't appear to be an answer.

I've updated the package for now to 4.5.0

zman0900 commented on 2015-12-09 02:19

I've noticed the same thing. Ideally there should be some way to prevent the auto updates, but short of that, maybe the unit file could be changed to auto-restart it on failure?

Edit: Actually, I see the auto-restart was just added for 4.4.1-2. Guess that doesn't actually work.

Edit2: Good news is just changing the package version and checksum was good enough to build the new version. 4.5.0 sha256 is 8a3ca9c01bf55051223f4f40e7dc086244fa07ea724a9f5d4552cf2752ad157b.

jdelisle commented on 2015-12-07 16:41

Not sure why, but when Crashplan tries to self-update the service dies. I can restart, and it'll run for a few hours, then when it tries to update itself, it dies again.

I can re-install from AUR (assuming this AUR package includes the latest-greatest from Crashplan), and I'm fine. Until they update again..

I thought I had a memory issue, but that wasn't it. I've tried the "archlinux-java fix" suggested in various forums.

I have no idea what's causing it to fail, and the logs are ridiculously verbose making any sort of digging into this quite difficult.

Anyone else having this issue? Tips?

[root@spider log]# systemctl status crashplan.service
● crashplan.service - CrashPlan Backup Engine
Loaded: loaded (/usr/lib/systemd/system/crashplan.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Fri 2015-12-04 02:03:56 CST; 3 days ago
Process: 4341 ExecStop=/opt/crashplan/bin/CrashPlanEngine stop (code=exited, status=0/SUCCESS)
Process: 3917 ExecStart=/opt/crashplan/bin/CrashPlanEngine start (code=exited, status=0/SUCCESS)
Main PID: 3940 (code=exited, status=0/SUCCESS)

Dec 04 02:03:22 spider systemd[1]: Starting CrashPlan Backup Engine...
Dec 04 02:03:23 spider CrashPlanEngine[3917]: Starting CrashPlan Engine ... Using standard startup
Dec 04 02:03:23 spider CrashPlanEngine[3917]: OK
Dec 04 02:03:23 spider systemd[1]: Started CrashPlan Backup Engine.
Dec 04 02:03:46 spider CrashPlanEngine[4341]: Stopping CrashPlan Engine ... /opt/crashplan/bin/CrashPlanEngine: line 144: kill: (3940) - No such process
Dec 04 02:03:56 spider CrashPlanEngine[4341]: Still running, killing PID=4526 ...
Dec 04 02:03:56 spider CrashPlanEngine[4341]: OK

justin8 commented on 2015-11-11 14:04

You need the same contents in that .ui_info file on both client and server. It is randomly generated when the server starts I believe. But just copy it from your server to the client and it will work. Prior to a few versions ago either this file didn't exist or it was never checked. So if you didn't update in a few months this will be a new problem that worked previously.

blackhole commented on 2015-11-11 13:16

Do you have /var/lib/crashplan/.ui_info?

Compizfox commented on 2015-11-11 13:06


I actually have Crashplan running on my headless server. However, I want the UI to connect to it from my Arch client.

justin8 commented on 2015-11-10 23:08

Yeah, that added that 'feature' a few versions ago. It's quite annoying.

fryfrog commented on 2015-11-10 22:55

The UI and server are two pieces, I think the server will fire up fine. I've honestly never tried to run the UI, my server is headless.

Instead, I use the UI from one of my Windows hosts and tell it to connect to the server. Their web site has directions for doing it, basically you modify a file and uncomment something and add an ip address. On the server, you have to tell it to listen on all ips instead of just localhost.

Or you can use SSH forwarding, if you know how and it is a little simpler... and a little more complex :)

Compizfox commented on 2015-11-10 22:27

Doesn't run here (no window showing up, no output in terminal).

I found this message in /opt/crashplan/log/ui_output.log:

com.backup42.desktop.CPDesktop] Failed to launch CPDesktop; .ui_info file not found

justin8 commented on 2015-11-05 18:18


fryfrog commented on 2015-11-04 18:27

Great idea, I'd love to see this too. I added it to mine locally a day or two ago when I realized it had croaked. :/

exz commented on 2015-11-04 14:04


Would you consider to add "Restart=on-failure" in systemd service file ?

zhimsel commented on 2015-10-30 04:16

I'm getting an error while trying to install via yaourt:

CrashPlan_4.4.1_Linux.tgz ... FAILED
crashplan ... Passed
crashplan.service ... Passed
install.vars ... Passed
sysctl-crashplan.conf ... Passed
==> ERROR: One or more files did not pass the validity check!
==> ERROR: Makepkg was unable to build crashplan.

I checked the PKGBUILD and the new sha256sum from below is in there.

marcosdsanchez commented on 2015-10-13 15:46

sha256sum changed.

7598e5eeb65179d20cd161f009214a1f4823a7479adbdca91a8ed57dbbfe6254 CrashPlan_4.4.1_Linux.tgz

justin8 commented on 2015-10-03 10:37

Thanks, I've updated it now.

You have to install with --force to overwrite the files. annoyingly there is no real way to stop crashplan from being able to overwrite its own files.

fryfrog commented on 2015-10-02 19:46

Here is a git patch that updates to 4.4.1, but because the CrashPlan client is self updating... if you've already got it installed, you'll get an error about (new?) files that already exist like I'm not sure what the right way to solve that is.

justin8 commented on 2015-09-15 20:59

@djhaines Thanks. Added.

dhaines commented on 2015-09-13 21:18

You may want to add (at least) /opt/crashplan/bin/run.conf to the backup array in the PKGBUILD. That, together with /opt/crashplan/conf/*, is a pretty common file to change and those changes would be nice to keep between versions.

justin8 commented on 2015-09-13 16:34

@cools Done.

justin8 commented on 2015-09-13 08:11

Sure. I just moved to a new country yesterday and won't have time to do it for a while. I could add you as a co-maintainer if you want?

cools commented on 2015-09-12 15:17

Any chance of adding in this OpenRC init script, for those of us not using systemd?

bobberb commented on 2015-07-24 04:18


Did you change anything besides -XmxYYYY? I still cannot get it to run with -Xmx2048m sadly.

jdelisle commented on 2015-07-17 22:26

@jdelisle - Answering my own comment.. for those googling.

Increase the memory available to Crashplan.

jdelisle commented on 2015-07-17 21:13

Just installed 4.3.0 off AUR4, and getting this after it's run for a few minutes:

Jul 17 11:32:22 foo CrashPlanEngine[16391]: Stopping CrashPlan Engine ... /opt/crashplan/bin/CrashPlanEngine: line 144: kill: (16057) - No such process

Anyone figure this out yet?

firecat53 commented on 2015-07-08 19:03

If anyone is having trouble with the Crashplan 4.3 upgrade connecting to a headless server:

- On the headless server, get the value of /var/lib/crashplan/.ui_info
- On the (linux) client, create or edit the file /var/lib/crashplan/.ui_info to match the value on the server, except the port should be (typically) 4200 instead of 4243


gabrielmoreira commented on 2015-05-15 18:15

@justin8: Thank you.

➜ ~ yaourt -S --force crashplan

Now it worked!

justin8 commented on 2015-05-15 13:32

Using force when installing with pacman will ignore file conflicts and install it correctly. I have no idea for yaourt, I imagine it can too, but you'd have to check the man page.

gabrielmoreira commented on 2015-05-15 12:57

@egeerardyn: Ok. Thank you.

I'm using manjaro, and every day it will notify that i need update crashplan package. What can i do? Can yaourt ignore errors and force install?

egeerardyn commented on 2015-05-15 12:24

@gabrielmoreira: This is most likely due to crashplan updating itself behind the scenes. It can be ignored safely.

gabrielmoreira commented on 2015-05-15 12:16

I'm getting this error: /opt/crashplan/lib/bcprov-jdk15on.jar exists in filesystem

Packages (1) crashplan-4.2.0-2

Total Installed Size: 27.05 MiB
Net Upgrade Size: 2.51 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring [#############################################################################] 100%
(1/1) checking package integrity [#############################################################################] 100%
(1/1) loading package files [#############################################################################] 100%
(1/1) checking for file conflicts [#############################################################################] 100%
error: failed to commit transaction (conflicting files)
crashplan: /opt/crashplan/lib/bcprov-jdk15on.jar exists in filesystem
Errors occurred, no packages were upgraded.
==> WARNING: Your packages are saved in /tmp/yaourt-tmp-gabriel
==> ERROR: unable to update


Current installed version:

➜ ~ yaourt -Q crashplan
local/crashplan 3.7.0-2

justin8 commented on 2015-04-25 00:59

Cheers. Fixed.

sajan commented on 2015-04-21 22:20

The 'crashplan.service' file still needs to be edited to fix the Waiting For Connection issue. Instead of just the network-online After target, it needs a matching Wants target as well.

See this thread:


justin8 commented on 2015-04-07 01:52

Good point, I didn't realize that was a valid target. I've updated it now, and bumped to v3.7.0

davermont commented on 2015-04-06 02:31

I think 'After=network-online' might fix the "Waiting for connection" problem.

zaidan commented on 2015-03-02 13:08

Please add dependency to net-tools:

# grep /opt/crashplan/log/service.log.0
...Exception running ifconfig cmd=[/sbin/ifconfig], Cannot run program "/sbin/ifconfig"...
...Exception getting router ip! Cannot run program "netstat"...

spatz commented on 2015-01-16 11:49

Looks like crashplan won't work without polkit. I get:

Failed to start crashplan.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files

Works fine after installing polkit manually, so it should be added as a dependency.

orschiro commented on 2015-01-13 15:48


/opt/crashplan/bin/run.conf could be moved to /opt/crashplan/bin/run.conf.pacsave during update process.

butler360 commented on 2015-01-13 15:24

Is there a way to make changes to /opt/crashplan/bin/run.conf persist after upgrades? I keep having to change back the amount of memory allocated when there's an upgrade.

hoban commented on 2015-01-05 17:40

Some of us are having issues after system updates a couple of weeks ago. Crashplan just started sending out emails to those of us affected, so this will probably come up more frequently soon.
Here's an initial comment describing the issue:

justin8 commented on 2014-12-20 01:03


I started double checking it before I saw your second comment. I just defaulted it to en_US since that should be ok for most people (even though I don't use it):

justin@ironwood  echo ${LANG-en_US.utf8}
justin@ironwood  echo ${NOTLANG-en_US.utf8}

atommixz commented on 2014-12-19 19:57

ups, I understend. I'm wrong

atommixz commented on 2014-12-19 19:55

echo "LC_ALL=${LANG-en_US.utf8}" >> "$srcdir/CrashPlan-install/scripts/run.conf"
i think is incorrect for me
$ locale

justin8 commented on 2014-12-15 00:09

Hmm. I'm not sure where the LC_ALL=C part came from then. I seem to have had it since I adopted the package. Anyway; thanks for that. Changed it to $LANG with a fallback to en_US.utf8 now which should work for most people.

egeerardyn commented on 2014-12-14 12:02


You need a UTF8 compatible locale there ( as was the case when I gave you my code , i.e. ), because otherwise you cannot restore files with non-ASCII characters (that is also documented in the comments here somewhere around August 2012).

justin8 commented on 2014-12-14 00:19



I can't find references to the ticket that was in the comments; and the LC_ALL part was there when I took over the package. I've commented it out for now.

phiresky commented on 2014-12-13 22:46


The line

echo "LC_ALL=C" >> "$srcdir/CrashPlan-install/scripts/run.conf"

in the PKGBUILD disables backing up of files with unicode names for me: (should be ähä).

Removing the line fixes it.

orschiro commented on 2014-10-26 06:40


Thank you! The updated .desktop file works.

justin8 commented on 2014-10-26 03:53

Done. Also added in all the provided resolutions of icons, and bumped to 3.6.4

orschiro commented on 2014-10-24 06:11


Can you please change the icon line to a relative path in order to make Crashplan compatible with custom icon themes?

- Icon=/opt/crashplan/skin/icon_app_64x64.png
+ Icon=crashplan

Thank you!

jskier commented on 2014-09-10 13:07

Stopped working 4 days ago, complaining about locale:
/opt/crashplan/bin/CrashPlanEngine: line 110: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8): No such file or directory

justin8 commented on 2014-09-01 15:13

I don't use the Oracle JRE, and openjdk is the one that is supported in the distros, feel free to change the install.vars upon install, but looking at the jre7 pkgbuild, on line 81 it symlinks /opt/java/bin/java to /usr/bin/java anyway. If you are having issues with the java path in /usr/bin you may want to raise it with the JRE maintainer as that is the path it should be accessible in if it is supposed to fulfil the java-runtime-headless dependency.

Zuf commented on 2014-09-01 12:58

Variable JAVACOMMON=/usr/bin/java in install.vars file is wrong for oracle's JRE (JDK package from aur). In this case it should be JAVACOMMON=/opt/java/bin/java.

justin8 commented on 2014-08-07 23:36

@egeerardyn: thanks

Updated per fixes provided by marcelhuberfoo

egeerardyn commented on 2014-08-07 15:29

There you go.

I think it should be possible to merge everything (mine only has 32 commits, so together with git rerere it is still manageable to merge/rebase either your on my branch into the other by hand).

justin8 commented on 2014-08-07 15:01

Thanks, I've already got all my packages in a git repo, and I'm not sure as though I would be able to merge your history in to it. It can't hurt to give it a shot though if you want to send me a link to it.

egeerardyn commented on 2014-08-07 14:36

I've orphaned the package since I haven't spent any time on it in months, as you can see. I do have a git repo lying around with its history since I began maintaining it. Let me know if you'd like to have it, then I'll publish it somewhere.

justin8 commented on 2014-08-07 14:17

I noticed the package still wasn't fix and was unmaintained. The GUI crashing should be fixed now, and the dependencies are actually relevant again. Let me know if you have any issues.

@EtiennePerot: Done.

justin8 commented on 2014-07-30 01:35

This package still puts a sys-v style init script in /etc/rc.d.

orschiro commented on 2014-06-16 08:14

I was able to trace back the issue. I installed the latest jre 8u5-1 package. But Crashplan is currently incompatible with Java 1.8.

How can we reflect this in the dependencies of this package?

orschiro commented on 2014-06-08 10:26

For some reasons Crashplan stopped working for me.

Can someone reproduce the following error message?

Jun 08 11:05:20 thinkpad systemd[1]: Starting CrashPlan Backup Engine...
Jun 08 11:05:20 thinkpad CrashPlanEngine[987]: Starting CrashPlan Engine ... Using standard startup
Jun 08 11:05:20 thinkpad CrashPlanEngine[987]: OK
Jun 08 11:05:20 thinkpad systemd[1]: Started CrashPlan Backup Engine.
Jun 08 11:05:20 thinkpad systemd[1]: crashplan.service: main process exited, code=exited, status=127/n/a
Jun 08 11:05:20 thinkpad CrashPlanEngine[1005]: Stopping CrashPlan Engine ... /opt/crashplan/bin/CrashPlanEngine: line 144: kill: (1002) - No such process
Jun 08 11:05:30 thinkpad CrashPlanEngine[1005]: OK
Jun 08 11:05:30 thinkpad systemd[1]: Unit crashplan.service entered failed state.

EtiennePerot commented on 2014-06-07 18:32

Confirming the issue by butler360. I had gigabytes of restart.*.log files piling up, to the extent that shell expansion didn't work anymore ("bash: too many arguments" or something to that extent). Had to use `find -name 'restart.*.log' -delete` to get rid of them. Uncommenting APP_BASENAME in installs.vars seems to fix it.

landor commented on 2014-05-19 12:31

@egeerardyn: I am confirming the gui segfault issue as well as the fix reported by richli.

0112358 commented on 2014-05-10 22:11

Package works well but should there be a tray icon? I don't see one using xmonad/xmobar/trayer.

justin8 commented on 2014-05-05 09:50

Just checking in to report that I required that fix as well in order to make the GUI work again.

butler360 commented on 2014-04-28 00:16

I had to use that Mozilla line to get the interface to open, too, but I was also seeing errors in the /opt/crashplan/bin/restart*.log for missing Engine name. It also created so many restart logs I couldn't delete them with rm, I had to use find. The file it referenced was on line 21. That file led me to install.vars, where it loads the variables. For some reason in the install.vars the APP_BASENAME was commented out, which seems to have been causing the restart error logs. I commented it back in and now it seems to be working normally.

richli commented on 2014-03-12 17:34

I had to learn some sed-fu, but this sed one-liner in the package() function looks like it does the trick:

$ diff -Naur PKGBUILD PKGBUILD-new
--- PKGBUILD 2014-03-12 11:32:34.911232140 -0600
+++ PKGBUILD-new 2014-03-12 11:32:30.711104635 -0600
@@ -69,6 +69,10 @@
echo "" >> $srcdir/CrashPlan-install/scripts/run.conf
echo "export LC_ALL=$LANG" >> $srcdir/CrashPlan-install/scripts/run.conf

+ # Fix for the GUI segfaulting
+ #
+ sed -i '/^GUI_JAVA_OPTS=/s|"$| -Dorg.eclipse.swt.browser.DefaultType=mozilla"|' $srcdir/CrashPlan-install/scripts/run.conf
install -D -m 644 $srcdir/CrashPlan-install/install.vars $pkgdir/opt/$pkgname/install.vars
install -D -m 644 $srcdir/CrashPlan-install/EULA.txt $pkgdir/opt/$pkgname/EULA.txt
install -D -m 644 $srcdir/CrashPlan-install/EULA.txt "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"

orschiro commented on 2014-03-07 08:00


I can confirm the fix is working!

Can you patch the package, please?

jdarnold commented on 2014-03-06 17:00

Yeah, it fixed it for me too.

BTW, in the future, you may like to know that errors are dumped into a log file found here: /opt/crashplan/log/ui_error.log

ultdev commented on 2014-03-06 15:30

I just tried the fix and it works for me.

egeerardyn commented on 2014-03-06 08:31

@orschiro: Doesn't the page from Code42 solve it??

As I'm not running Arch Linux that often anymore, I can't easily confirm the behavior myself unfortunately. If more people confirm this behavior (and/or the fix), I will happily hard-code it for everyone.

orschiro commented on 2014-03-06 07:24


I can confirm it. I type `CrashPlanDesktop`, the startup window is shown, goes away, and then it seems to crash. No error output in console.

Strange. Any ideas?

richli commented on 2014-03-05 19:16

Anyone else noticing the GUI client segfaulting a few seconds after starting up? I found that this fixed the problem for me:

FalconGER commented on 2014-02-16 23:03

works :) thanks @dmast3r1

dmast3r1 commented on 2014-02-14 05:50



dmast3r1 commented on 2014-02-14 05:49



FalconGER commented on 2014-02-13 23:47

3.6.3 is out:

roknir commented on 2014-02-08 21:01

@egeerardyn: That did fix the problem for me.

(Thanks for the help despite not doing more digging myself. I haven't had the time lately.)

egeerardyn commented on 2014-02-03 08:55

@orschiro, @roknir:
There is an error in the current crashplan.install file. On line 8, the third " should be changed to \". I will upload a changed version later.

orschiro commented on 2014-02-02 20:46


Just tried manual building and installation. Works fine here.

Did you try rebuilding crashplan? Maybe something went wrong during building.

roknir commented on 2014-02-02 20:37

I am just using the standard, manual way.

orschiro commented on 2014-02-02 20:15


I cannot confirm that. At least not when using Aura AUR helper. You might try that? However, it would be odd if it is working with a helper but not the manual way.

roknir commented on 2014-02-02 19:55

I'm getting some errors when installing the latest version. Anyone know why?

justin8 commented on 2013-12-26 02:56

FYI, it should be /etc/sysctl.d/99-crashplan.conf it took me a while to figure out why the inotify change was not being applied on boot. It was because (as the manpage for sysctl.d states) only *.conf is read for sysctl.d

egeerardyn commented on 2013-12-12 19:58

@jrylander: that should not be a suggestion, that is a genuine error from my side. I will update the files.

jrylander commented on 2013-12-12 19:07

Suggestion, change:

sudo echo fs.inotify.max_user_watches=1048576 > /etc/sysctl.d/99-crashplan


sudo "sh -c echo fs.inotify.max_user_watches=1048576 > /etc/sysctl.d/99-crashplan"

orschiro commented on 2013-12-12 10:09


Thanks. I added the information to the wiki.

JohnShaft commented on 2013-12-12 03:31

Make sure you install networkmanager-dispatcher-crashplan-systemd if you are using Network Manager otherwise Crashplan will not be able to connect to Crashplan Central

hoban commented on 2013-11-15 21:00

Please update crashplan.install to indicate that the sysctl setting 'fs.inotify.max_user_watches' should be made to /etc/sysctl.d/99-sysctl.conf or some other file within /etc/sysctl.d/, rather than /etc/sysctl.conf as is currently indicated.

On new installs, with systemd, if this setting isn't made in the correct spot, it can lead to issues such as not being able to log in if the gnome screensaver is loaded and other odd behavior.

"Note: From version 207, systemd only applies settings from /etc/sysctl.d/* and /usr/lib/sysctl.d/*. If you had customized /etc/sysctl.conf, you need to rename it as /etc/sysctl.d/99-sysctl.conf."

orschiro commented on 2013-11-13 16:55


I cannot reproduce this. I do not have the package installed and do not have any connection issues.

What is the output of `systemctl status crashplan`

mattalexx commented on 2013-11-13 16:23

This package can't connect to CrashPlan's server ("CrashPlan Central") without installing the inotify-tools package. I was getting "Unable to backup - No connection for X days".

orschiro commented on 2013-11-06 14:56


I will first wait for your update. $LANG seems to be correct for now and everything runs fine if I simply remove the export line. If I keep the line but change utf8 to UTF-8 it still raises the error.

~ $ echo $LANG

egeerardyn commented on 2013-11-04 10:13


There are no changes with respect to the locale settings in my upcoming patches, only with respect to rc.d / sysctl.

Yes, the LC_ALL is needed to prevent a bug from happening (as I've explained before): otherwise, people with diacritics (e.g. garçon.pdf, café.doc, ...) in the filenames do not have a functional back-up. (See comments in August 2012 or the PKGBUILD). I will NOT leave out that line unless I'm 200% certain that is does not reintroduce that bug, you are always free to change the PKGBUILD before building.

In the corresponding ticket from CrashPlan/Code42, their resolution is:

" This is an issue we have seen occasionally with Linux users and international character sets. It stems from the ANSI character set.

The default 'root' user's character set during startup is ANSI. The problem is resolved simply by restarting CPS. However, the problem returns again after system restart. This only happens when CPS is run as 'root'. It usually won't happen if running as a user.

To resolve, please add the following line to /usr/local/crashplan/bin/run.conf :

export LC_ALL=en_US.UTF-8

You can use a different locale than en_US if you'd like. The UTF-8 portion is the important part. This specifies that CrashPlan will always use a UTF-8 charset instead of ANSI, which is the system default."

And this is the one we use here as well.

If you have LC_ALL=en_US.utf8 in run.conf, that means that your $LANG is set to that, as the PKGBUILD uses your $LANG environment variable to configure the daemon, as you can see in the PKGBUILD. So to make it clear: I don't set LC_ALL to anything fixed, it is extracted from the (installing) user's configuration. If the value is invalid, this means your configuration is invalid (or that I've overlooked some incompatibility by assuming that $LANG and $LC_ALL accept the same values or that setting the value is done improperly, but I really doubt that is the case). Off course, feel free to inspect my code in the PKGBUILD to point out any error or to debug the problem you are having.

In your case, I indeed suspect it might be as simple as changing utf8 to UTF-8, but probably you will have the same problem after an upgrade. So you should have a look at finding the cause for this on your system.

orschiro commented on 2013-11-03 22:36


Thanks. I may then wait for your patches and see how things change. Just an idea, but could it be as simple as one has to use `LC_ALL=en_US.UTF-8` instead of `LC_ALL=en_US.utf8`?

I could not find a single config in which utf8 is used.

Overall, removing the export line from run.conf does not affect crashplan at all. The client is starting without a problem. Thus, are you sure that a locale has to be exported for a root system daemon to work properly?

egeerardyn commented on 2013-11-03 17:10

It is required by crashplan to export the locale: it is NOT up to the user (account) as the user doesn't run crashplan: that is a system daemon. I'm also not putting the LC_ALL to US English, but to the configuration of the user (see PKGBUILD). We need some locale, and I settled on the one of the installing user because if we don't, it breaks the back-up of people using diacritics in their file names (which is a big no-no to me).

Either your locale is not set properly (as before), or, something has changed since I last checked my Arch computers. Unless there are multiple people that cannot run Crashplan because of the error you encounter, I'm not that keen on doing anything about it.

With regard to the rc.d script (and the outdated sysctl conf that gesh is mentioning), we don't really need it for the reason you stated. But I haven't put much time in Arch packages since I've moved on to Mac OS as main platform. I will try to test the patches I already have lying around on my Arch boxes before uploading them.

orschiro commented on 2013-11-03 16:39


Can you please remove `export LC_ALL=en_US.utf8` from run.conf?

It causes the error already reported below:

Aug 06 22:34:08 thinkpad systemd[1]: Ignoring invalid environment 'export LC_ALL=en_US.utf8': /opt/crashplan/bin/run.conf

It is not required by Crashplan to export the locale as this is up to the user. If I remove the export command from run.conf and add it in turn to my user config, then I don't experience that error anymore.

Furthermore, do we still need /etc/rc.d/crashplan as the old initscript approach is depreciated?

gesh commented on 2013-10-23 20:49

Note: /etc/sysctl.conf is unsupported since 2013-09-17[1]
Therefore, the advice in crashplan.install to change the max_user_watches
setting there should instead point to /etc/sysctl.d/some_sysctl.

[1] -

orschiro commented on 2013-08-07 19:29

Resolved. I added `export LC_ALL=en_US.utf8` to `~/.bashrc`. Thanks for the hint.

egeerardyn commented on 2013-08-07 12:46

@orschiro: I suppose your locale is set improperly. I'm not an expert, but consulting should get your set-up right on track.

egeerardyn commented on 2013-08-07 10:49

@orschiro: I suppose your locale is set improperly. I'm not an expert, but consulting should get our set-up right on track.

orschiro commented on 2013-08-07 09:32


That is strange then. In `/etc/locale.gen` `en_US.UTF-8 UTF-8` and `en_US ISO-8859-1` is uncommented but running `locale` shows `LC_ALL=`.

Any ideas?

egeerardyn commented on 2013-08-07 09:25


That should only occur if you had the locale en_US.utf8 enabled during the install of this package and have it disabled now. Normally, it shouldn't be critical, as CrashPlan should then use a fallback locale to operate. What might happen, however, is that this locale is not Unicode-compatible (i.e. special characters in file names might not be backed-up properly). This has been discussed about a year ago in this thread.

orschiro commented on 2013-08-06 20:37

Can anyone confirm the following error message in `journalctl`:

Aug 06 22:34:08 thinkpad systemd[1]: Ignoring invalid environment 'export LC_ALL=en_US.utf8': /opt/crashplan/bin/run.conf

It is highlighted in red colour. How critical is this error?

dmast3r1 commented on 2013-06-21 21:14

in makepkg change

and set the first md5 to


then build as normal = up to date

orschiro commented on 2013-03-31 10:39

I suddenly have the problem that Crashplan interface is no longer starting as user but only root. The engine is running.


Any ideas?

orschiro commented on 2013-03-05 13:19


Thanks. That is what I was wondering about. I was still running 3.4.2 and Crashplan did not show any attempt to upgrade by itself.



egeerardyn commented on 2013-03-05 13:18

@orschiro: normally, CrashPlan upgrades behind the scenes, so yes, you are probably already running the latest version. In any case, I have updated the package.

orschiro commented on 2013-03-05 12:14

What about the new 3.5.2 release?

Do we get the new version automatically?

roknir commented on 2013-01-20 18:27

Sorry -- I figured my problem out myself. It was crashing due to the amount of memory it was allowing Java to use. To fix this, I did:

$ sudo systemctl stop crashplan.service

Edit /opt/crashplan/bin/run.conf

SRV_JAVA_OPTS="-Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Dnetworkaddress.cache.ttl=300 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false"

Change the -Xmx512m to -Xmx1024m

$ sudo systemctl start crashplan.service

All better. Hopefully this helps if someone else has the same problem.

roknir commented on 2013-01-20 18:17

Has anyone else had problems with crashplan continually restarting?

egeerardyn commented on 2013-01-18 18:17

@Zopieux: I included this in the new release. Thanks for submitting.

zopieux commented on 2013-01-18 11:50

To get this package to work with another Java environment (eg. JRE), edit the PKGBUILD when asked and replace
echo "JAVACOMMON=/usr/bin/java" >> install.vars
echo "JAVACOMMON=`which java`" >> install.vars

orschiro commented on 2012-12-08 20:01

Forgot to mention that the service is successfully running:

[orschiro@thinkpad ~]$ sudo systemctl status crashplan.service
[sudo] password for orschiro:
crashplan.service - CrashPlan Backup Engine
Loaded: loaded (/usr/lib/systemd/system/crashplan.service; enabled)
Active: active (running) since Sa, 2012-12-08 20:43:03 CET; 15min ago
Process: 561 ExecStart=/opt/crashplan/bin/CrashPlanEngine start (code=exited, status=0/SUCCESS)
Main PID: 576 (java)
CGroup: name=systemd:/system/crashplan.service
└─576 /usr/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanSe...

Dez 08 20:43:03 thinkpad systemd[1]: Started CrashPlan Backup Engine.
Dez 08 20:43:03 thinkpad CrashPlanEngine[561]: Starting CrashPlan Engine ......p
Dez 08 20:43:03 thinkpad CrashPlanEngine[561]: OK

orschiro commented on 2012-12-08 19:58

Does someone face the same problem that sometimes after boot Crashplan just waits for an connection although the connection is already established?


orschiro commented on 2012-11-30 16:05

Thanks for your help.

All solved now.

egeerardyn commented on 2012-11-30 08:00

@orschiro: I don't know why you have that as 777, but that is not a desirable permission for most files. Just change it to 755 indeed.

orschiro commented on 2012-11-30 07:47

Sorry to bother again. Another warning:

warning: directory permissions differ on opt/crashplan/upgrade/UpgradeUI/
filesystem: 777 package: 755

Should I change the directory permissions to 755?

orschiro commented on 2012-11-30 07:43

@egeerardyn: Cheers a lot. pacman -Qo indeed did the trick. Again I learned something about package owning. :)

egeerardyn commented on 2012-11-30 07:40

@orschiro: you can check with pacman which package owns what files (look at the man page for the exact syntax, although it might be mentioned in this thread as well). From the name of those files, it wouldn't surprise me they aren't owned by any package. But only you can check that on your computer.

orschiro commented on 2012-11-30 07:36

I would assume that they are owned by crashplan since they are in /opt/crashplan folder.

egeerardyn commented on 2012-11-30 07:35

@orschiro: if they are not owned by any package, yes you can.

orschiro commented on 2012-11-30 07:30


Thanks for the update.

So I am safe to remove files in /opt?

Proceed with installation? [Y/n]
(1/1) checking package integrity [######################] 100%
(1/1) loading package files [######################] 100%
(1/1) checking for file conflicts [######################] 100%
error: failed to commit transaction (conflicting files)
crashplan: /opt/crashplan/lang/ exists in filesystem
crashplan: /opt/crashplan/lang/ exists in filesystem
crashplan: /opt/crashplan/lang/ exists in filesystem
Errors occurred, no packages were upgraded.
==> WARNING: Your packages are saved in /tmp/yaourt-tmp-orschiro
==> ERROR: unable to update

egeerardyn commented on 2012-11-16 06:01

Updated to 3.4.1.

As always, you can safely ignore the file conflicts of files that are not owned by any package as CrashPlan updates in the background.

roguewolf commented on 2012-11-01 14:55

Many thanks for the information.

donniezazen commented on 2012-11-01 14:14


egeerardyn commented on 2012-11-01 14:01

@roguewolf : why don't you test it? I guess the daemon should run flawlessly.

roguewolf commented on 2012-11-01 13:49

Forgive my ignorance but is it possible to run Crashplan on a headless box or is the GUI required?

donniezazen commented on 2012-10-20 15:49

It failed to find Java. I use jdk package from AUR. I edited java location in PKGBUILD and then installed. It's working fine. Thanks.

egeerardyn commented on 2012-10-20 07:51

@donniezazen: with that little information I cannot debug it here and it is working properly on all my computers.
Can you try to start the engine manually (the command is stated in your log). If you want more direct help, please just mail me.

donniezazen commented on 2012-10-17 12:02

Crashplanengine is not working properly.

systemctl status crashplan.service
crashplan.service - CrashPlan Backup Engine
Loaded: loaded (/usr/lib/systemd/system/crashplan.service; enabled)
Active: failed (Result: exit-code) since Wed, 17 Oct 2012 05:57:58 -0600; 57s ago
Process: 926 ExecStop=/opt/crashplan/bin/CrashPlanEngine stop (code=exited, status=0/SUCCESS)
Process: 414 ExecStart=/opt/crashplan/bin/CrashPlanEngine start (code=exited, status=0/SUCCESS)
Main PID: 864 (code=exited, status=127)
CGroup: name=systemd:/system/crashplan.service

Oct 17 05:57:47 arch CrashPlanEngine[414]: Starting CrashPlan Engine ... Using standard startup
Oct 17 05:57:48 arch CrashPlanEngine[414]: OK
Oct 17 05:57:48 arch systemd[1]: Started CrashPlan Backup Engine.
Oct 17 05:57:48 arch CrashPlanEngine[926]: Stopping CrashPlan Engine ... /opt/crashplan/bin/CrashPlanEngine: line 144: kill: (864) - No such process
Oct 17 05:57:58 arch CrashPlanEngine[926]: OK

egeerardyn commented on 2012-10-12 05:42

@ericab (who has by now deleted his comment): If you want to contact me directly, please send a mail with exactly what you tried and what failed. I'm not that often on IRC for support.

egeerardyn commented on 2012-09-23 06:23

Indeed, it should be able to run without SWT as it includes its own SWT jars. I removed the dependency again as it might be too heavy for people working in a headless environment.

@awayand: by "don't start", do you mean that the deamon/service won't start or the GUI/client? Can you check whether you have SWT jars in /opt/crashplan/lib and whether those are used (using e.g. `lsof | grep swt`)? I guess that there is something out of the ordinary with your particular configuration. If you haven't modified the PKGBUILD or other crashplan files, don't hesitate to send me an email if you want further assistance.

chadberg commented on 2012-09-23 02:42

Also works fine without swt here...

jonandermb commented on 2012-09-22 16:50

I have a little problem setting up the directory for the inbound backups.... anyone can help?

egeerardyn commented on 2012-09-22 13:40

@J4913: Hmm, indeed. I can also run it without swt installed. Apparently, the needed libraries are included with CrashPlan in /opt/crashplan/lib.

J4913 commented on 2012-09-22 13:22

Strange, it's working without swt here.

egeerardyn commented on 2012-09-22 13:20

@awayand: added as a dependency in 3.2.1-10. Thanks for reporting!

Anonymous comment on 2012-09-22 13:12

needs swt as dependency, if installed on a clean arch system without swt crashplan wont startup

J4913 commented on 2012-09-16 19:12

Well, I get it with the standard rc.d init script too.

egeerardyn commented on 2012-09-16 19:06

I will take a look at it when I return from holidays in a week; but I have to say I'm not an expert in systemd.

J4913 commented on 2012-09-16 19:00

With the recent-ish changes to the init scripts, CrashPlan now takes quite a while to stop (5-10 seconds, using systemd) - and obviously this means my shutdown time is slow. Any ideas for getting rid of this?

donniezazen commented on 2012-09-12 00:48

@ultdev Thank you. Solved it.

ultdev commented on 2012-09-11 23:51

Change "echo "JAVACOMMON=/usr/bin/java" >> install.vars" to "echo "JAVACOMMON=/opt/java/jre/bin/java" >> install.vars" in the PKGBUILD.

donniezazen commented on 2012-09-11 23:41

I have jdk/jre package installed in opt and not in /usr/bin. Is their a way to make Crashplan work with /opt/java/jre/bin.

egeerardyn commented on 2012-08-17 07:22

@scwalla: thanks for notifying me. Code42 made some small changes, breaking the MD5 checksum in the PKGBUILD (coincidentally one of the changes appears to disable MD5 inside CrashPlan).

In the meanwhile, I also changed some minor things.

During the update you MAY get a file conflict on /opt/crashplan/lang/, you can safely force the update. I'll see if I can get Crashplan to behave better in that respect.

egeerardyn commented on 2012-08-17 05:44

@scwalla: thanks for notifying me. Code42 made some small changes, breaking the MD5 checksum in the PKGBUILD (ironically, one of the changes appears to disable MD5 inside CrashPlan).

In the meanwhile, I also changed some minor things.

During the update you MAY get a file conflict on /opt/crashplan/lang/, you can safely force the update.

scwalla commented on 2012-08-16 22:12

CrashPlan_3.2.1_Linux.tgz fails md5sum in 3.2.1-8

scwalla commented on 2012-08-16 22:10

egeerardyn commented on 2012-08-13 20:41

@J413: thanks. I must have looked over that one.

It is fixed, crashplan now uses /usr/bin/java which should work for Java 6 and 7 (Java 5 is way beyond end-of-life, so I don't really care if that breaks).
That is the only change for release 3.2.1-8.

J4913 commented on 2012-08-13 20:26

$ pacman -Qo /usr/bin/java
/usr/bin/java is owned by jre7-openjdk-headless 7.u5_2.2.1-1

egeerardyn commented on 2012-08-13 20:22

@J4913: It seems a fix is not that straightforward. Realtime parameter expansion doesn't seem to work for me, but at least on Java 6, it is statically referenced using /usr/bin/java, but I can't find this for Java 7 in the repositories (would you mind to tell me if you do have it on your system, and if so, by which package it is owned ("pacman -Qo /usr/bin/java")).

I will try to fix it during the weekend since it is just a minor bug for which a workaround is known.

J4913 commented on 2012-08-13 20:14

Ah, yes, that's exactly what I did, and that's why the update fixed it. Thanks.

egeerardyn commented on 2012-08-13 19:50

@J4913: Thank you for reporting this. It is somewhat controlled by me: Crashplan uses the $JAVAHOME variable *during install* to determine which one to use. On a standard install, this should point to the JRE, but if you have the JDK installed, it will point in that direction. The only case where this practice might cause problems, is when you remove the JDK after the installation of CrashPlan. But that can be worked around by installing CP again after the removal.

I will test whether I can keep the variable unexpanded in the configuration files without any problems. That way it will still point to the JDK (which is perfectly fine, IMHO), but it should migrate fluently when updating Java or removal of the JDK.

egeerardyn commented on 2012-08-13 19:49

@J4913: Thank you for reporting this. It is somewhat controlled by me: Crashplan uses the $JAVAHOME variable *during install* to determine which one to use. On a standard install, this will point to the JRE, but if you have the JDK installed, it will point in that direction. The only case where this practice might cause problems, is when you remove the JDK after the installation of CrashPlan. But that can be worked around by installing CP again after the removal.

I will test whether I can keep the variable unexpanded in the configuration files without any problems. That way it will still point to the JDK (which is perfectly fine, IMHO), but it should migrate fluently when updating Java or removal of the JDK.

J4913 commented on 2012-08-13 19:45

...Actually, ignore that; just updated from -5 to -7, and I'm not sure what you changed, but it works now.

J4913 commented on 2012-08-13 19:28

CrashPlan seems to be using /usr/lib/jvm/java-7-openjdk/bin/java, which is a symlink to /usr/lib/jvm/java-7-openjdk/jre/bin/java. The latter is provided by the JRE, and the former by the JDK. I'm not sure whether it's in the package or CrashPlan itself that this path is set, but if it's under your control, the latter would be better.

egeerardyn commented on 2012-08-11 15:21

I've included a unit for systemd, but it is not the one mseiwald provided. It uses the CrashPlanEngine script by Code42. On one hand, this might be a bit ugly and old-fashioned; but on the other hand that keeps the package as close to the official one as possible (so easier to get support from Code42, easier to update, less prone to uncommon bugs, etc.).
Since I only installed systemd this afternoon, if some people with more experience think it should be done differently, don't hesitate to speak up.

egeerardyn commented on 2012-08-09 21:17

@mseiwald: Thank you. If all goes well, I will be updating my systems to use systemd during the weekend, so that's also the moment when I will package your script.
I'm also going to check whether the current method (using both rc.d and the proper crashplan scripts) and yours is functionally equivalent to keep regressions to a minimum.

mseiwald commented on 2012-08-09 21:06

I have create a systemd unit file:

I've been using this for some weeks without problems. Care to include?

jdarnold commented on 2012-08-07 20:26

Thanks for checking it out. To be honest, I'm not sure why it says I have the C locale. And as far as I know, I don't need it. I'll see what I can do about changing it.

egeerardyn commented on 2012-08-07 17:24

The C locale is not compatible with the CrashPlan scripts at the moment and I prefer not to change those too much unless something really breaks (it only gives a spew of warnings on my machine). Is there a specific reason why that locale is useful (to you or in general)?

I do have some ideas that work around your problem:
- either run the install with `export LANG=...` set (and ... not the C or POSIX locale)
- or edit /opt/crashplan/bin/run.conf in a similar way.

The problem is that the CrashPlanEngine (and rc.d script) appends ".UTF-8" to the setting (while first removing any other possible encoding), which for C or POSIX does not give a valid locale. I can make the rc.d daemon somewhat more compatible (as it uses the same constructs at the moment), but that will just lessen the problem without solving it.

jdarnold commented on 2012-08-07 16:34

$ locale

I have "en_US.UTF-8 UTF-8" uncommented.

jdarnold commented on 2012-08-07 14:16

You don't need a subscription to do a backup, at least an onsite or to a friend's computer.

I do get an error (warning?) when I start crashplan in rc.conf - something about the LANG variable. I'll try to figure out if it gets logged somewhere.

egeerardyn commented on 2012-08-07 06:57

@perost: I don't expect any problems. I ran some small tests with backing up files with Swedish characters and restoring them afterwards on the same system with en_US-utf8. It all ran without any problem.

Anonymous comment on 2012-08-07 06:29

The updated PKGBUILD fixes my problems with UTF-8 characters, and it now finds all files as it should. I haven't tried to do an actual backup yet since my trial expired, but I'm going to buy a subscription and try later when I have some time. But I don't anticipate any problems with that. Thank you Egon!

egeerardyn commented on 2012-08-01 21:58

I contacted Code42 and they knew a solution. It is caused by CrashPlan running as root, but the locale isn't properly set for that case.
The PKGBUILD is updated to use the $LANG variable to enforce that encoding in CrashPlan, so this error should not happen anymore.

Please check after updating (and restarting the daemon) that the correct names are shown in CrashPlan (which is what I found on my install). If this isn't the case, the support guy from Code42 recommended to unselect files to be back-upped with garbled names, save and reopen the file dialog and select the files which should then have proper names and save again.

egeerardyn commented on 2012-07-29 22:34

I can reproduce the problem, but I haven't found a solution yet. Apparently CrashPlan finds the file, but it gets a FileNotFound exception when trying to open it. When I have some time, I will try to find the cause of this problem.

Anonymous comment on 2012-07-13 10:38

Is UTF-8 characters in filenames working for anyone with Crashplan? For me they just show up as � in the file list, and crashplan doesn't recognize folders with such characters as folders. Any folder with UTF-8 characters is thus not backed up for me. locale returns sv_SE.utf8 for everything. Do you need to set the encoding somewhere else for crashplan to pick it up?

NobodySpecial commented on 2012-07-12 00:37

Thanks J4913 and egeerardyn - worked great!

J4913 commented on 2012-07-11 07:42

Yeah, that's because CrashPlan is silly and auto-updates itself with root privileges. The only option is to just delete those files, then install the package - you know it's safe because 'pacman -Qo' on each of those files can't find an owner.

NobodySpecial commented on 2012-07-11 01:17

This now compiles fine, but won't actually install:
error: failed to commit transaction (conflicting files)
crashplan: /opt/crashplan/lang/ exists in filesystem
crashplan: /opt/crashplan/lang/ exists in filesystem
crashplan: /opt/crashplan/lang/ exists in filesystem
crashplan: /opt/crashplan/lib/c42_protolib.jar exists in filesystem
crashplan: /opt/crashplan/lib/json-lib-2.4.jar exists in filesystem
crashplan: /opt/crashplan/lib/log4j-1.2.16.jar exists in filesystem
crashplan: /opt/crashplan/lib/protobuf-java-2.4.1.jar exists in filesystem
crashplan: /opt/crashplan/lib/trove-3.0.2.jar exists in filesystem
crashplan: /opt/crashplan/ exists in filesystem
Errors occurred, no packages were upgraded.

egeerardyn commented on 2012-07-10 13:20

I have made a new release that removes those 64 bit libraries on 32 bit installs. Please let me know if you have other problems or if that solves it for you.

egeerardyn commented on 2012-07-10 04:38

@NobodySpecial: are you by any chance running on a 32 bit version of Arch? In that case I suspect you can just delete the libraries that end in 64 before building. I will try to update the package to fix this, but at the moment I don't have access to a 32 bit testing machine.

NobodySpecial commented on 2012-07-09 22:29

Doesn't work for me:
strip:./opt/crashplan/ File format not recognized
/usr/bin/fakeroot: line 181: 25752 User defined signal 1 FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@"

egeerardyn commented on 2012-07-09 18:20

I've taken over maintaining this package.
Changes since the last update:
- updated to the latest version (3.2.1)
- adapted the daemon script to amyers's suggestion (thanks!) with some small tweaks on top
- no more interactive prompt to read the EULA, just a notice to do so instead

Feel free to inspect, criticize or provide suggestions.

Anonymous comment on 2012-04-26 11:21

I was having really severe connection issues with Crashplan 3.2. I initially thought they were due to the version of java-runtime I was using but then saw issues on all versions. I changed the daemon script to use the CrashPlanEngine script and it now seems completely reliable. Fair warning, this is the first time I've messed with a daemon script so YMMV, maybe someone who knows what they're doing could clean it up.

#!/usr/bin/env bash

. /etc/rc.conf
. /etc/rc.d/functions

if [[ -f /etc/profile.d/ ]]; then
. /etc/profile.d/
elif [[ -f /etc/profile.d/ ]]; then
. /etc/profile.d/


test -f $VARS || exit 0
test -f $CONFIG || exit 0
test -f $CRASHPLAN || exit 0


if [[ ${LC_ALL} ]]; then
LOCALE=`sed 's/\..*//g' <<< ${LC_ALL}`
export LC_ALL="${LOCALE}.UTF-8"
elif [[ ${LC_CTYPE} ]]; then
LOCALE=`sed 's/\..*//g' <<< ${LC_CTYPE}`
export LC_CTYPE="${LOCALE}.UTF-8"
elif [[ ${LANG} ]]; then
LOCALE=`sed 's/\..*//g' <<< ${LANG}`
export LANG="${LOCALE}.UTF-8"
export LANG="en_US.UTF-8"

[[ `$CRASHPLAN status` != "CrashPlan Engine is stopped." ]] && PID=`$CRASHPLAN status | sed -r 's/CrashPlan Engine \(pid ([0-9]+)\).*/\1/'`

case "$1" in
stat_busy "Starting CrashPlan Engine"
cd $WD
[[ -z "$PID" ]] && nice -n 19 $CRASHPLAN start
if [ $? -gt 0 ]; then
add_daemon crashplan
cd $PWD
stat_busy "Stopping CrashPlan Engine"
[[ ! -z "&PID" ]] && $CRASHPLAN stop &> /dev/null
if [ $? -gt 0 ]; then
rm_daemon crashplan
$0 stop
sleep 1
$0 start
echo "Usage: $0 <start|stop|restart|status>" >&2
exit 3

fabertawe commented on 2012-04-23 16:02

I'm having a problem with the GUI - very faint blue on white. As a result I can't read anything on the interface!

I'm not familiar with Java, is there a way to change the colour scheme?


Anonymous comment on 2012-04-13 16:21

CrashPlan doesn't seem to handle connectivity issues gracefully. If the daemon's started before your network is available, it refuses to reconnect to CrashPlan Central. I had to create a separate script to manage the crashplan daemon and run it with POST_UP/POST_DOWN via netcfg. It's really just a while loop that waits until it finds an Internet connection (i.e., is ping-able).

J4913 commented on 2012-03-27 12:44

I'm also finding I need a larger delay than 1s in the restart, or it doesn't start - I'm using 5s ATM, which works, but might be an overestimate.

NobodySpecial commented on 2012-03-16 08:47

j4913 - thanks for your help, it is inexplicably running again now, so all is well!

J4913 commented on 2012-03-15 09:24

Is the daemon running, then? 'ps -ef | grep -i crashplan' show anything? Anything in /opt/crashplan/engine_{error,output}.log?

NobodySpecial commented on 2012-03-15 01:38

jdarnold - yes, I have it in the DAEMONS line. If I do that or if I start / stop manually, it still doesn't work.

jdarnold commented on 2012-03-14 03:23

Did you add 'crashplan' to the DAEMONS line in rc.conf, @NobodySpecial?

J4913 commented on 2012-03-12 11:10

It's still working fine here - 'Connection status' under Destinations/Online/CrashPlan Central says 'Connected for 1 hour'.

NobodySpecial commented on 2012-03-12 10:50

Crashplan isn't working anymore. The GUI says "Waiting for connection." Anybody else have this problem?

NobodySpecial commented on 2012-02-09 12:16

J4913 - thanks for the info, working great for me with your patches.

J4913 commented on 2012-02-01 23:11

Also, you need to change

sub("^ ", "", $0);


sub("^ *", "", $0);

to account for PIDs below 1000.

J4913 commented on 2012-02-01 15:31

*This pidfile thing

J4913 commented on 2012-02-01 15:31

This pifile thing doesn't seem to be working - stopping the service rarely works because it doesn't have the daemon's PID, or has more than one. Why not just do

PID=`/bin/ps -eo 'pid,cmd'| grep 'app=CrashPlanService' | grep -v grep | awk '{sub("^ ", "", $0); print $0}' | cut -d " " -f 1`

like you do for status, instead of


? And just don't bother with deleting/writing to the pidfile. It seems to work fine here.

deimos commented on 2012-01-08 03:10

"Just as a note I needed to make a change to the file /opt/crashplan/install.var by changing the JAVACOMMON variable from /usr/java to $(which java) and everything seemed to move forward from there. Although you do need to startup the daemon separately from the desktop app." -- brianbourke75 (

scwalla commented on 2012-01-04 21:38

The problem only occurs on 32 bit systems. /usr/bin/strip is run on all binaries and fails on the 64 bit ones.

adding options=(!strip) to PKGBUILD succeeds as a work-around.

jono commented on 2012-01-02 14:50

Worked for me. I am using OpenJDK 7. All I had to do was add "crashplan" to my rc.conf DAEMONS.

chadberg commented on 2011-12-16 22:46

Installs beautifully once I remove the whitespace from the pkgrel line in PKGBUILD

scwalla commented on 2011-11-11 22:21

I am using openJDK. Anyone having success with that?

orschiro commented on 2011-11-11 19:45

Are you using openjdk oder jre?

It is just a guess but it might be related to the differences in java runtime.


scwalla commented on 2011-11-11 03:07

Build fails with errors as shown below:
-> Stripping unneeded symbols from binaries and libraries...
/usr/bin/strip:./opt/crashplan/ File format not recognized

==> ERROR: An unknown error has occurred. Exiting...

==> ERROR: An unknown error has occurred. Exiting...
The build failed.

orschiro commented on 2011-10-28 17:51

With CrashPlanEngine you mean the daemon?

I do the following:

sudo /etc/rc.d/crashplan start && sleep 5 && CrashPlanDesktop


Dieter_be commented on 2011-10-28 10:25

I also needed to chown -R dieter:root /opt/crashplan.
I start the CrashplanEngine as my user (are we supposed to start it as root?) and it couldn't write its pid with the default permissions.

Anonymous comment on 2011-10-24 00:26

I also confirm Dieter's comment. Edit /opt/crashplan/install.vars and make JAVACOMMON=/usr/bin/java.

orschiro commented on 2011-10-12 09:14

I can confirm Dieter's comment. Can this be changed in the PKGBUILD or is this a problem of the application itself?


jsteel commented on 2011-10-04 20:17

java-runtime doesn't exist; should this be changed to openjdk6?

Dieter_be commented on 2011-09-30 15:18

I needed to edit /opt/crashplan/install.vars and make JAVACOMMON=/usr/bin/java