Synology NAS: Running CrashPlan in Docker Container

BACKGROUND

The reason to run CrashPlan in Docker container is to prevent any future Synology’s DSM updates from breaking the CrashPlan app.

Let’s assume the Synology NAS IP address is 1.2.3.4.

STEPS

Diskstation Manager

Log into Diskstation Manager: http://1.2.3.4:5000

Install Docker.

Package Center -> Utilities -> Third Party -> Docker

Mac

SSH into Synology NAS.

ssh admin@1.2.3.4

Install CrashPlan Docker container.

sudo docker pull jrcs/crashplan

Run CrashPlan Docker container. In this example, we want to backup photo and video directories.

sudo docker run -d --name CrashPlan \
 -p 4242:4242 -p 4243:4243 \
 -v /volume1/photo:/volume1/photo -v /volume1/video:/volume1/video \
 jrcs/crashplan:latest

Back to Diskstation Manager

Get authentication token from the running CrashPlan.

Docker -> Container -> CrashPlan -> Details -> Terminal -> Create -> bash

Run command:-

cat /var/lib/crashplan/.ui_info

The following text are printed:-

4243,########-####-####-####-############,0.0.0.0

Copy ########-####-####-####-############ to somewhere first.

By default, CrashPlan allocates 1GB of memory. The recommendation is to allocate 1GB of memory per 1TB of storage to prevent CrashPlan from running out of memory. In this example, we are going to increase it to 3GB.

Edit /var/crashplan/conf/my.service.xml.

vi /var/crashplan/conf/my.service.xml

Change the following line:-

<config ...="">
	...
	<javamemoryheapmax>3072m</javamemoryheapmax>
	...
</config>

Edit /var/crashplan/app/bin/run.conf.

vi /var/crashplan/app/bin/run.conf

Change the following line:-

SRV_JAVA_OPTS="... -Xmx3072m ..."
GUI_JAVA_OPTS="..."

Stop CrashPlan Docker container.

Docker -> Container -> CrashPlan -> Action -> Stop

Enable auto-restart on CrashPlan Docker container.

Docker -> Container -> CrashPlan -> Edit -> General Settings -> Enable auto-restart -> OK

Start CrashPlan Docker container.

Docker -> Container -> CrashPlan -> Action -> Start

Back to Mac

Download and install CrashPlan software.

Disable CrashPlan service since the UI acts as a client.

sudo launchctl unload -w /Library/LaunchDaemons/com.crashplan.engine.plist

Edit /Applications/CrashPlan.app/Contents/Resources/Java/conf/ui.properties.

sudo nano /Applications/CrashPlan.app/Contents/Resources/Java/conf/ui.properties

Uncomment serviceHost and update Synology NAS IP address.

#Fri Dec 09 09:50:22 CST 2005
serviceHost=1.2.3.4
#servicePort=4243
#pollerPeriod=1000  # 1 second
#connectRetryDelay=10000  # 10 seconds
#connectRetryAttempts=3
#showWelcome=true

#font.small=
#font.default=
#font.title=
#font.message.header=
#font.message.body=
#font.tab=

Edit /Library/Application Support/CrashPlan/.ui_info.

sudo nano "/Library/Application Support/CrashPlan/.ui_info"

Replace the authentication token with the value from above step. Replace IP address with Synology NAS IP address.

4243,########-####-####-####-############,1.2.3.4

Finally, run CrashPlan app to view the backup process.

Git + Linux: (gnome-ssh-askpass:24871): Gtk-WARNING **: cannot open display:

PROBLEM

When running git clone on Linux, the following error appears:-

-bash-4.1$ git clone http://user@tfs:8080/tfs/my-institution/my-domain/_git/my-project
Initialized empty Git repository in /people/my-group/user/my-project/.git/

(gnome-ssh-askpass:24871): Gtk-WARNING **: cannot open display:

SOLUTION

To fix this, run the following command to disable gnome-ssh-askpass:-

-bash-4.1$ unset SSH_ASKPASS

Now, git clone will work just fine:-

-bash-4.1$ git clone http://user@tfs:8080/tfs/my-institution/my-domain/_git/my-project
Initialized empty Git repository in /people/my-group/user/my-project/.git/
Password:
remote:
remote:                    fTfs
remote:                  fSSSSSSSs
remote:                fSSSSSSSSSS
remote: TSSf         fSSSSSSSSSSSS
remote: SSSSSF     fSSSSSSST SSSSS
remote: SSfSSSSSsfSSSSSSSt   SSSSS
remote: SS  tSSSSSSSSSs      SSSSS
remote: SS   fSSSSSSST       SSSSS
remote: SS fSSSSSFSSSSSSf    SSSSS
remote: SSSSSST    FSSSSSSFt SSSSS
remote: SSSSt        FSSSSSSSSSSSS
remote:                FSSSSSSSSSS
remote:                  FSSSSSSs
remote:                    FSFs    (TM)
remote:
remote:  Microsoft (R) Visual Studio (R) Team Foundation Server
remote:
Receiving objects: 100% (504/504), 1.05 MiB, done.
Resolving deltas: 100% (138/138), done.

To prevent this from happening again, add unset SSH_ASKPASS command to .bashrc file.

Windows 10 Was NOT My Idea, But It Was Free

So, I decided to make use of the complimentary upgrade from my current Windows 7 running on VirtualBox to Windows 10. Not exactly the smoothest process, but I got it working after 5 days.

I’m listing all the problems I encountered and the solutions I applied to get my free toy that I rarely use.

PROBLEM: “Get Windows 10” icon not showing on taskbar

To fix this, run all Windows updates first. In my case, I had to upgrade my Windows 7 to SP1 for that icon to show up.

PROBLEM: “CPU isn’t supported” error

When clicking on “Get Windows 10”, you may get “CPU isn’t supported” error.

To fix this, shut down guest VM. Then, check “Enable PAE/NX” setting in VirtualBox.

PROBLEM: “Get Windows 10” error report doesn’t refresh

It appears Microsoft configures Windows 10 Compatibility Appraiser to run every once awhile.

To fix this, force it immediately because my time is money.

schtasks.exe /Run /TN "\Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser"

Wait for a few minutes before checking the error report.

PROBLEM: “Virtualbox Graphics Adapter was not compatible with Windows 10” error

Okay, this is pure bull.

To fix this, download Media Creation Tool and use that to perform the upgrade instead.

PROBLEM: Progress stuck at 0% for hours

When running media creation tool, the progress may be stuck at 0% or whatever percentage for hours. Well, the Microsoft servers are overloaded.

To fix this, rerun Media Creation Tool, say 5AM in the morning… works for me.

PROBLEM: “Setup has failed to initialize the working directory” error

Basically, the guest VM doesn’t have enough space for Windows 10 upgrade.

To fix this, shut down guest VM.

Then, increase the virtual space by running the following command on the host. In my case, I increased my virtual size to 100GB.

VBoxManage modifyhd "/Users/Shitty Author/VirtualBox VMs\Windows 7\Windows 7.vdi” --resize 102400

Now, increase the actual space by first downloading GParted Live ISO.

In VirtualBox, add this ISO to “IDE Controller”. Make sure CD is booted before hard drive.

Run guest VM.

When GParted Live gets loaded, use the default values by hitting Enter keys several times.

Expand the existing NTFS drive space accordingly.

Restart guest VM.

Rerun Media Creation Tool… and hopefully it works this time.

What Now?

Well, now I have Windows 10 Pro running in VirtualBox, together with Ubuntu, Centos, Fedora and Android OS.

In reality, I will only use Windows 10 to test my software and spend 99.9% of my time on Mac.