Restarting always broke something

[fdecourt]

Hi JrCs,
I have a problem with your container. When launching for the first time, it works well, using this command :
docker run -d --name crashplan2 -p 4242:4242 -p 4243:4243 -v /docker/crashplan/data:/var/crashplan -v /volume1:/volume1 jrcs/crashplan:latest
But if I restart it, then nothing work.
I am running on a Synology.
Here are some logs :
2017-01-20 00:33:53 stderr tail: cannot open '/var/crashplan/log/service.log.0' for reading: Symbolic link loop
2017-01-20 00:33:53 stderr touch: cannot touch '/var/crashplan/log/service.log.0': Symbolic link loop
2017-01-20 00:33:53 stderr /etc/init.d/crashplan: line 42: /var/crashplan/app/bin/CrashPlanEngine: Symbolic link loop
2017-01-20 00:33:53 stderr mv: failed to access '/var/crashplan/conf': Symbolic link loop

Thanks a lot for your support

[JrCs]

What FS do you using for the volumes ?
What version of docker also ?

[fdecourt]

Hi, my FS is ext4 and the docker version is 1.6.2.036 (based on the synology info)

[rossdargan]

I'm having this same issue. Works fine, restarting breaks it. Need to recreate the image, then "adopt" the old machine. It then works until I next restart it.

[RobbieG3]

Same issue. After restarting, I get "Unable to connect to the backup engine, retry?". Connecting from Windows over the network to your Docker container on a QNAP TVS-873. Re-downloading and updating the ip address in the .ui_info file does not fix the problem. Happy to share logs.

Not sure if this is related or helpful, but this is the last thing in the Docker console when I try to connect (censored guid and location/public address):
[04.11.17 23:38:55.067 INFO DefaultGroup .code42.messaging.peer.PeerGroup] PG::DefaultGroup RemotePeer not allowed to connect, missing PbK. RemotePeer-[guid=############ ######]; PeerConnectionState-[state=DISCONNECTED, mode=PRIVATE, currentAddressIndex=0, layer=2/2(Peer::NIO), connecting=2017-04-11T23:37:26:749, connected=0, disconnected =2017-04-11T23:37:35:051, attempts=0, connectActivity=2017-04-11T23:37:35:051, keepAliveSent=0, minRetry=32759, reconnectable, location=###.###.###.###:4242, transportPbK= null, transportPbKRequestable=false, public=###.###.###.###:4242]; Session-null

[georgemaxim]

After I restart the container will not start again wining something about "loop symlinks".

If I restart using the command restart in CrashplanUI I will not be able to reconnect using UI no mater what I do.

After restart from incoming backup are not accessible. Checked permissions all are root:users 775. All should be editable at this point.

Thanks.

FWIW I have the same issue. If I run the build command (either with the noted port command or I've tried with the --net=host switch) The initial build works. But if I have to shut down the container for anything it becomes un-accesible. I've even noticed that my NAS no longer even is listening on the port:

admin@NAS:/volume1$ netstat -ano | grep 4243
tcp6       0      0 127.0.0.1:4243          :::*                    LISTEN      off (0.00/0/0)

[alongfield]

I am also having this exact problem, which prevents me from using the container at all, unfortunately. I need to increase the Java heap for the size of my backups, which requires a restart that never comes back.

I'm running Docker 1.11.2-0329 on a Synology NAS and using the latest image for CrashPlan. Filesystem is btrfs, and the first container start is fine.

I generated my container like so:

docker run -d --name="crashplan" --net="bridge" -p 4242:4242 -p 4243:4243 -e TZ="US/Eastern" -h quanta.internal.wire-head.org -v "/volume1/crashplan":"/var/crashplan":rw -v "/volume1/crashplan-storage":"/storage":rw -v "/volume1":"/volume1":ro -v "/volume2":"/volume2":ro -v "/volume3":"/volume3":ro -v "/volume4":"/volume4":ro jrcs/crashplan

And after a restart I get these errors:

/etc/init.d/crashplan: line 42: /var/crashplan/app/bin/CrashPlanEngine: Symbolic link loop touch: cannot touch '/var/crashplan/log/service.log.0': Symbolic link loop tail: cannot open '/var/crashplan/log/service.log.0' for reading: Symbolic link loop

The problem is that something is messing up the directories under /var/crashplan/app and making bin, cache, jre, lang, lib, and log all by a symlink back to itself.

/var/crashplan/app after restart:

lrwxrwxrwx 1 root root 22 Jul 8 16:55 bin -> /var/crashplan/app/bin
lrwxrwxrwx 1 root root 24 Jul 8 16:55 cache -> /var/crashplan/app/cache
lrwxrwxrwx 1 root root 22 Jul 8 16:55 jre -> /var/crashplan/app/jre
lrwxrwxrwx 1 root root 23 Jul 8 16:55 lang -> /var/crashplan/app/lang
lrwxrwxrwx 1 root root 22 Jul 8 16:55 lib -> /var/crashplan/app/lib
lrwxrwxrwx 1 root root 22 Jul 8 16:55 log -> /var/crashplan/app/log

What it should be is like this, from the initial startup:

drwxrwxr-x 1 root root 122 Jul 8 17:05 bin
drwxr-xr-x 1 root root 0 Jul 8 17:05 cache
drwxr-xr-x 1 root root 222 Dec 30 2016 jre
drwxrwxr-x 1 root root 602 Dec 30 2016 lang
drwxrwxr-x 1 root root 3836 Dec 30 2016 lib
drwxr-xr-x 1 root root 206 Jul 8 17:05 log

I haven't figured out what's messing this up, but I did notice that there is a /usr/local/crashplan with the same files, symlinks, and layout. There is also a /usr/local/bin/CrashPlanDesktop that is a link to /usr/local/crashplan/bin/CrashPlanDesktop, but /usr/local/bin is a symlink to /var/crashplan/app/bin, and that's a symlink to /var/crashplan/app/bin, so another loop.

Maybe this is a regression introduced in entrypoint.sh when moving from /usr/local/crashplan to /var/crashplan? It looks like that will always overwrite the good with the bad on the next run.

[schmod]

I'm also seeing the same problem.

Bummer - happened again. I should have known better than to reboot my NAS. Anyone find any solution besides rebuilding the entire docker container?

[visualinventor]

To expand on this further looks like the binaries are removed and there are only symbolic links left in place. I cannot follow a symlink and not get another symlink. There are no files that end at the binaries or log folders.

[pconwell]

@visualinventor Looks like this project has been abandoned? I switched over to this project and it has worked very well for me.

Plus, being able to access the crashplan GUI through a web browser has been really nice.

[addf]

Hi guys,

Just in case someone is still facing this problem. After trying to dig in the entrypoint.sh, doing changes, and reviewing the different layers of the FS at the container, I was not able to solve it (indeed I even broke more a few times).

What worked for me was to simple go to the docker interface, select the previous Crashplan container, stop it, go to settings -> duplicate settings -> create a new container with the same settings, run it, log into the container, get the new id from the id/.ui_info, update my script and connect successfully to it.

I did a computer adoption, and so far everything seems to be working fine.

I wonder if in any shutdown, the container did corruct or something like that to make it fail in the filesystem level.

I hope it works for you guys.

[vt2001cpe]

Which version of the desktop GUI are you using to connect to the Docker container? I still have 4.8 Home and it worked until the container became corrupted. I was wondering if there is a newer version I should install?

…

On Sun, Nov 12, 2017 at 9:53 AM, Antonio ***@***.***> wrote: Hi guys, Just in case someone is still facing this problem. After trying to dig in the entrypoint.sh, doing changes, and reviewing the different layers of the FS at the container, I was not able to solve it (indeed I even broke more a few times). What worked for me was to simple go to the docker interface, select the previous Crashplan container, stop it, go to settings -> duplicate settings -> create a new container with the same settings, run it, log into the container, get the new id from the id/.ui_info, update my script and connect successfully to it. I did a computer adoption, and so far everything seems to be working fine. I wonder if in any shutdown, the container did corruct or something like that to make it fail in the filesystem level. I hope it works for you guys. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVhXtv7m78cxx8MJsh3snD9KpNCWy2LSks5s1wZTgaJpZM4Loyca> .