[Support] Djoss - CrashPlan


Recommended Posts

6 minutes ago, Djoss said:

I never tried this kind of scenario, but I think you need the "Unsassigned Devices" plugin to mount your external HDD.  Is it what you did?

Then, in container settings, you need to add a "Path".  Your disk should be under '/mnt/disks/'.  I think the mode should be RO/Slave or RW/Slave for unassigned devices.

 

Actually, the XML file automatically maps /mnt/disks to /unassigned in RO/slave mode. So remove the mapping you added and look for your usb disk under /unassigned.  

 

If you need to write to the disk, switch to advanced view and change the mapping from RO/slave to RW/slave

 

I don't have any actual experience with this, but it should work :) 

Link to comment
22 minutes ago, Djoss said:

Since in general it's better to use the bridge mode, I think it's not worth adding complexity to support host mode.  However, you could achieve it by using the existing X11VNC_EXTRA_OPTS variable.

 

Thanks!  I use host mode to deal with LAN backups, seemed simpler than adding a static route. Your readme was super helpful with this, btw!

 

23 minutes ago, Djoss said:

You could just append a message to the CrashPlan's log file that would trigger the notification

 

of course, I should have thought of that :)

 

23 minutes ago, Djoss said:

Make sure to update to the latest version, as I did some fixes related to unRAID notifications.

 

I haven't been able to try it yet, but I've looked at the code. Won't the container need the root password in order to access "http://$IP_ADDR:${PORT:-80}/webGui/include/Notify.php" ?  

 

Also, on 6.4 with SSL enabled, the container will need an environment variable for the FQDN to use in place of the IP address.

Link to comment
8 minutes ago, ljm42 said:

Actually, the XML file automatically maps /mnt/disks to /unassigned in RO/slave mode.

In fact it's no longer the case (it would create issues for people not using it).  If you installed the container in the early days, you may have this mapping.  But recent installations don't.

Link to comment
3 minutes ago, ljm42 said:

I haven't been able to try it yet, but I've looked at the code. Won't the container need the root password in order to access "http://$IP_ADDR:${PORT:-80}/webGui/include/Notify.php" ?  

No, because it uses the csrf token.

 

4 minutes ago, ljm42 said:

Also, on 6.4 with SSL enabled, the container will need an environment variable for the FQDN to use in place of the IP address.

Yeah, I will have to adjust to 6.4...

Link to comment
8 minutes ago, Djoss said:

In fact it's no longer the case (it would create issues for people not using it).  If you installed the container in the early days, you may have this mapping.  But recent installations don't.

 

Oh! Yes I was an early adopter, I guess I should remove the mapping from my system then :) In that case, it might be something you want to cover in the readme?

Link to comment
6 minutes ago, ljm42 said:

 

Interesting!  Presumably other pages require a password in addition to the token, but that is good news if this one does not. Sorry for doubting you :) 

 

But make sure to try it, in case I'm the only one for who it's working ;)

Link to comment
5 hours ago, Djoss said:

 

I never tried this kind of scenario, but I think you need the "Unsassigned Devices" plugin to mount your external HDD.  Is it what you did?

Then, in container settings, you need to add a "Path".  Your disk should be under '/mnt/disks/'.  I think the mode should be RO/Slave or RW/Slave for unassigned devices.

Thanks for the reply.  Yes, I used "Unassigned Devices".  I will try to add a path when I get a chance.

 

Unfortunately, I seem to be having a problem and I believe it is with using Crashplan.  I had the server reboot a couple of times on Sunday.  I think it was related to Crashplan and figured it was because I was messing around with it so much.  I wish I would have pulled the container logs because they looked weird.  Anyhow, I decided to turn it back on and continue my backups between my 2 servers yesterday.  It ran all day and rebooted again this morning while I was at work.  I did disable autostart so it didn't keep happening.  Weird that my backup server has been running Crashplan since Saturday and hasn't had a problem.  This is the last like of the container log:

18/07/2017 07:40:51 destroyed xdamage object: 0x20002e

Mean anything to you?  Let me know if you need any other info that would be of help.  Thanks.

 

Edit:  Based upon server up time, it appears that it rebooted around 12:30 p.m. today.  Although, I think it has something to do with Crashplan, I can't be for sure.  I did just switch out the motherboard, cpu and memory and upgrade from 6.1.x to 6.3.5 :)  Although it is using the same HDDs, cache drive, flash drive and HDD controller.

Edited by icon123
Link to comment

Why exactly did you restart the server? Because it became unresponsive? Were you able to ping it?
What is your backup size and the number of files?
In the appdata folder of CrashPlan, there is a folder for logs. You can look at them to see if there is anything interesting.

Link to comment
20 minutes ago, Djoss said:

Why exactly did you restart the server? Because it became unresponsive? Were you able to ping it?
What is your backup size and the number of files?
In the appdata folder of CrashPlan, there is a folder for logs. You can look at them to see if there is anything interesting.

Maybe I wasn't clear in my post.  The server has auto rebooted three times now.  And it has only happen when I have Crashplan running.

My backup size is 207k files, 1.3TB, setting memory to 2GB.  Total memory is 8GB.

Like I said, maybe its premature since I changed so much of my configuration, but it seems like it has only rebooted when Crashplan is running.  Maybe just a coincidence.  I'm not taking any chances though and have a different motherboard, cpu and memory coming.  I will do a mem test on the new setup prior to doing anything.  I tried to look at the crashplan logs on Sunday, but nothing stood out, not that it would of necessarily either.  There is a lot of info in them.  So if nothing strikes you off the top of your head, then I will wait until I receive the new hardware and do so more testing.

Link to comment

I added this mapping:

"/var/local/emhttp":"/var/local/emhttp":ro

and then simulated an error:

echo "OutOfMemoryError occurred...RESTARTING!" >> /mnt/user/appdata/CrashPlan/log/service.log.0

According to the docker log, it detected the problem but was unable to notify:

ERROR: CrashPlan is running out of memory. More memory needs to be allocated. This can be done via the CRASHPLAN_SRV_MAX_MEM environment variable.

[monitor] notify_unraid: Failed to send notification.


I poked around /etc/services.d/monitor/run and saw that it got passed the csrf token to the correct url. When I tried it manually I was prompted to login:

http://192.168.10.51/webGui/include/Notify.php?csrf_token=xxxxx

So I modified the curl line to pass the user/pass in the url:

  curl --fail  \
         -d "cmd=add" \
         -d "e=$APP_NAME Docker Application" \
         -d "s=$TITLE" \
         -d "i=$LEVEL" \
         -d "d=$MSG" \
         -d "$CSRF_TOKEN" "http://root:PASSWORD@$IP_ADDR:${PORT:-80}/webGui/include/Notify.php"

and then notifications worked.  So unfortunately, it appears that the container does need the root password in order to do notifications. Definite bummer.

 

This was on unRAID 6.3.5 BTW.

Link to comment
2 hours ago, Djoss said:

This mapping should have been added automatically.  Do you have the Fix Common Problems plugin installed?

 

Yes I do have FCP installed.

But as far as I know, there is not an automated way to incorporate developer-provided changes in the XML file after a docker has been installed

Link to comment
2 hours ago, Djoss said:

So I understood what happened:  somehow I forgot the fact that I don't have a root password password set on my setup... :/ 

 

LOL np. Now go add that password! :) 

 

So I left my modified docker running and got a notification last night!

Event: CrashPlan Docker Application
Subject: CrashPlan's memory consumption comes critically close to its limit.
Description: 95% of allocated memory is used.  Increase memory allocation to avoid unexpected crashes.  This can be done via the CRASHPLAN_SRV_MAX_MEM environment variable.
Importance: alert

This type of proactive notification is exactly what we need to keep CrashPlan running smoothly, I love it!

 

These are the options I see to solve this, do any of them look good to you? Do you see any others?

  1. Have LT remove the authentication requirement from Notify.php. This sounds scary, but as long as it requires the CSRF token the chance for abuse is small.
  2. Write a plugin with its own webserver that runs on a different port and mimics the functionality of Notify.php.  Seems overly complicated.
  3. Have Dockers write files to a shared directory which a new plugin reads and creates notifications from. This option has the most promise I think. It would also simplify the code on the docker side, as it would just write files and wouldn't have to figure out the CSRF token or FQDN, etc.
Link to comment
3 minutes ago, ljm42 said:

 

LOL np. Now go add that password! :) 

 

So I left my modified docker running and got a notification last night!


Event: CrashPlan Docker Application
Subject: CrashPlan's memory consumption comes critically close to its limit.
Description: 95% of allocated memory is used.  Increase memory allocation to avoid unexpected crashes.  This can be done via the CRASHPLAN_SRV_MAX_MEM environment variable.
Importance: alert

This type of proactive notification is exactly what we need to keep CrashPlan running smoothly, I love it!

 

These are the options I see to solve this, do any of them look good to you? Do you see any others?

  1. Have LT remove the authentication requirement from Notify.php. This sounds scary, but as long as it requires the CSRF token the chance for abuse is small.
  2. Write a plugin with its own webserver that runs on a different port and mimics the functionality of Notify.php.  Seems overly complicated.
  3. Have Dockers write files to a shared directory which a new plugin reads and creates notifications from. This option has the most promise I think. It would also simplify the code on the docker side, as it would just write files and wouldn't have to figure out the CSRF token or FQDN, etc.

Already working on #3 :)

Link to comment

I just installed this new CrashPlan container.  I am a longtime user of the other CrashPlan docker.  The adoption process went fine and all files in my various backup sets show as missing.  No big deal, I know I just have to add them again.  The problem is that under mnt/user it does not show the all the folders I need to backup.  I can only browse to whatever is the parent directories stated in the existing backup sets.  If I remove one (done as a test) of the existing folder in the set, /mnt/user is as far as I can browse and I cannot even see folders beyond that.  Basically I cannot re-add the correct folders and I cannot browse beyond /mnt/user to add additional folders. 

 

I completely removed the other container, image and folders from appdata before installing this docker container.

 

Permissions issue?  What do I need to fix.

Link to comment
17 minutes ago, Djoss said:

Not sure if I understood your issue properly, but inside the container, your files should be under /storage.

 /storage is mapped to /mnt/user. This, of course, is where all the user shares are (Pictures, Movies, Videos, etc.) that I wish to backup.

 

In the WebGUI, I cannot browse to anything beyond mnt/user unless it was already in the backup set (and all of those show as "missing"); so, I cannot add to right folders to the backup sets.

 

I stopped and restarted the CrashPlan container and now the WebGUI will not even load at [ipaddress]:7804

 

UPDATE: Just restarted container again and now WebGUI loads

Edited by Hoopster
Link to comment
3 minutes ago, Hoopster said:

In the WebGUI, I cannot browse to anything beyond mnt/user unless it was already in the backup set (and all of those show as "missing"); so, I cannot add to right folders to the backup sets.

I meant when you browse your file in CrashPlan, do not go under '/mnt/user'.  Instead, browse to '/storage'.  Is it what you are doing?

 

 

Link to comment
Just now, Djoss said:

I meant when you browse your file in CrashPlan, do not go under '/mnt/user'.  Instead, browse to '/storage'.  Is it what you are doing?

 

 

Sorry, now I see it, duh!  I was still stuck doing things like I did in the other container.  Browsing "Storage" works as expected.  Of course, why else would you have that mapping if not to browse "storage."  Sorry for the bother.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.