Giter VIP home page Giter VIP logo

crashplan-docker-synology's Introduction

crashplan-docker-synology's People

Contributors

ajkerrigan avatar ebiancarelli avatar gitter-badger avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

crashplan-docker-synology's Issues

.ui_info missing

If I set this up on a new Synology, without any pre-existing Crashplan directories, where does the .ui_info file end up?

Starting the package works fine, however I cannot find the .ui_info file anywhere.

IP Address of container is not reachable from the LAN computers

Thank you for your work!
I'm hopeful this is more supportable vs the Patters synology packages that break monthly.


When I run the docker instance on my DS412+, it works great and can reach the CrashPlan online backup servers. The IP address of the docker instance is 172.17.0.1 (gateway: 172.17.42.1) and my lan subnet is 192.168.115.x. When the docker crash plan instance reports its info to the crash plan cloud, the 172 address is replicated to my LAN clients. This results is the LAN clients are not able to reach the docker instance.

Can I modify the docker network settings so that the docker container DHCPs on my network and treats the docker infrastructure as a bridge?

Container does not start after reboot

I applied the latest DSM upgrade a few days ago and thought that the container worked fine since I am using the latest version of this script. But after 3 days I got the email from Crashplan saying that my client had not been connected for 3 days.

So today when I looked closer I noticed that the Crashplan container had not mounted any of the user specified volumes. So I then recreated the container and when I checked again they were mounted properly.

So as one more step I wanted to reboot the Synology to check if the container started properly. But it did not start at all.

The following is logged in syslog of the Synology:

Apr 25 09:05:10 diskstation synoddsm-hostd_SYNO.Docker.Container_1_list[12808]: synoProfile.cpp:285 Profile /var/packages/Docker/etc/.config not exist
Apr 25 09:05:10 diskstation synoddsm-hostd_SYNO.Docker.Container_1_list[12808]: synoProfile.cpp:285 Profile /var/packages/Docker/etc/.config not exist
Apr 25 09:05:11 diskstation synoddsm-hostd_SYNO.Docker.Container_1_list: SYSTEM:        Last message 'synoProfile.cpp:285 ' repeated 1 times, suppressed by syslog-ng on diskstation
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = []
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [adoring_banach]
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [crashplan]
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [crashplan]
Apr 25 09:05:11 diskstation synoddsm-hostd: SYSTEM:     Last message 'util.cpp:105 SharePa' repeated 1 times, suppressed by syslog-ng on diskstation
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [trusty-crashplan]
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = []
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [adoring_banach]
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [crashplan]
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [crashplan]
Apr 25 09:05:11 diskstation synoddsm-hostd: SYSTEM:     Last message 'util.cpp:105 SharePa' repeated 1 times, suppressed by syslog-ng on diskstation
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [trusty-crashplan]
Apr 25 09:05:14 diskstation root: == DSM 6.0 7321-2 finished boot up ==

If I manually execute /usr/local/etc/rc.d/S99crashplandocker.sh status it starts properly.

Any hints on what goes wrong and where to start looking?

/usr/local/etc/crashplan: no such file or directory on START

First off: thanks for a great package!

I'm trying to install per Wiki instructions after a fresh install of DSM and Docker.

When starting the container via terminal, I'm getting seeing this:

/usr/local/etc/rc.d/S99crashplandocker.sh start
Found the user variables file. Updating...
CRASHPLAN_DIR=/usr/local/etc/crashplan
DATA_DIR=/volume1/CrashPlanBackups
USER_VOLUMES=-v /volume1:/volume1:ro
No existing CrashPlan container found. Running image "ajkerrigan/crashplan".
Unable to find image 'ajkerrigan/crashplan:latest' locally
latest: Pulling from ajkerrigan/crashplan
f069f1d21059: Pull complete
ecbeec5633cf: Pull complete
ea6f18256d63: Pull complete
54bde7b02897: Pull complete
a3ed95caeb02: Pull complete
ce9e695a6234: Pull complete
346026b9659b: Pull complete
d900dbe16dec: Pull complete
c599eff79b5a: Pull complete
Digest: sha256:cc665edccff63933b6bbdf765a6ea14236908ef28c941c9ff45d31e83e40935e
Status: Downloaded newer image for ajkerrigan/crashplan:latest
73f3ca6ad9972962036bfd21094e9a21490602c0e73be431fa4b9abc00a61656
/var/packages/Docker/target/usr/bin/docker: Error response from daemon: stat /usr/local/etc/crashplan: no such file or directory.

My version info:

  • DSM: 6.1-15047
  • Docker: 1.11.2, build bf60a63-synology

Looking through issue #9, it gives me hope there is a solution for this but not sure this is the same issue in play. Any suggestions?

Make use of the Wiki for documentation

I think the README has a lot of important information, but as bits have been added it's starting to get a bit unwieldy. It should probably be broken up, perhaps into a series of Wiki entries.

Synology md0 is running out of space

The Docker-image is running smoothly on my DS412+, thanks for the fine work!

I tried to install the latest update. Unfortunately it failed due to a lack of space on the system volume md0.
So I used the command:
/usr/bin/du -h -d 2 -x /usr/local/etc/
which gave me the information that crashplan is using ca. 1g of space:
12K /usr/local/etc/crashplan/id
761M /usr/local/etc/crashplan/cache
294M /usr/local/etc/crashplan/log
80K /usr/local/etc/crashplan/conf
20K /usr/local/etc/crashplan/bin
1.1G /usr/local/etc/crashplan

Wouldn't it be a good idea to move this directory to /volume1 e.g. /volume1/crashplan/?
This volume is much bigger and will not interfere with any DSM-updates.

Don't recommend storing files in /root

I had my git repo and cp-user-vars.sh in /root as recommended by the readme and just lost them after a DSM upgrade. Apparently DSM upgrades wipe /root.

Script does not start automatically after DSM 6.0 upgrade

After upgrading to DSM 6.0-7321, this script works if started manually. However, it does not start automatically on system boot.

Log file /var/log/upstart/3rdparty-services.log shows the following entry:

/usr/local/etc/rc.d/S99crashplandocker.sh: line 41: docker: command not found

Change the startup script to reference the full path to the docker binary.

Make deployment smoother

The "install" process at this point is some combination of cloning the git repo and then copying and/or symlinking files. That is probably not intimidating to anyone who is in the position to need a script like this in the first place, but it does feel a bit clunky. Since we have the luxury of a somewhat predictable environment, it may be worth having a light install script that does the initial symlinking in one shot.

In that case, it may make sense to "install" cp-user-vars.sh by default, with commented out path variables set to the same values as the script defaults. Customization would then be a matter of uncommenting and tweaking lines in that file.

Migrate from patters

Thanks for this repo. I was looking it over, and it seems to be missing instructions on how to migrate between Patters' package and your docker instance. Any advice?

No auth token in /config/id/.ui_info

Hi, thanks to your great documentation I managed to install, configure, and start the crashplan container. Unfortunately I do not manage to connect from my CrashPlan UI. Appears there is no authentication token in /config/id/.ui_info:

# cat /config/id/.ui_info
gets me
4243,unRAID

I expected the format to be:
4243,<token>,<localhost>

Any ideas how to fix this / how to connect from the UI?

BTW, I also noticed that the log files in /config/log are not being updated, despite the JAVA process being active. Should I look for logs at another location?

Many thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.