tigerdoc

Members
  • Content count

    18
  • Joined

  • Last visited

Community Reputation

0 Neutral

About tigerdoc

  • Rank
    Member

Converted

  • Gender
    Undisclosed
  1. tigerdoc

    [CONTAINER] CrashPlan & CrashPlan-Desktop

    @ljm42 -- Thanks for the memory tip. I updated to 3 GB and it has been running now for about a half hour without crashing. That may have solved it, at least for me. @Helmonder -- If you're using the new Appdata configuration, you'll find it at /mnt/user/Appdata/crashplan/bin/run.conf
  2. tigerdoc

    [CONTAINER] CrashPlan & CrashPlan-Desktop

    Thanks for the suggestion. Tried stopping and restarting CP --> no difference. Forced update and restarted CP --> no difference. CP appears to crash and restart about every 60 seconds. If I'm connected to webUI at the time, VNC says it lost the connection and then a few seconds later shows CP restarting.
  3. tigerdoc

    [CONTAINER] CrashPlan & CrashPlan-Desktop

    Has anyone had any issues since last night? Specifically, CrashPlan is stopping and restarting every minute or so. I am able to connect via web GUI and see the CP history showing entries starting CP 4.8.0 with the correct GUID and scanning for files. Those entries repeat about every minute, since 12:00 am today. I'm running CP 4.8.0 and Unraid 6.2.1. Thanks.
  4. I just updated to 6.2 from 6.1.9 and found I don't have the System share created. It is not listed in the share tab. I have a cache device, which the cache tab lists correctly. If I try to manually create a System share, I get a message that the System share has been deleted. Thoughts? Edited to add: Looking at the log, my server thinks the cache disk is full. From log: But the array lists it has having 1 TB free (it's a 1-TB disk with 28 MB on it currently). Any ideas why it would like the cache is full?
  5. tigerdoc

    [CONTAINER] CrashPlan & CrashPlan-Desktop

    Barakthecat and I have been having a problem for the last 43 days and I'm curious if anyone has had it and fixed it already. We were backing up very happily to each other for a while without trouble and now, at least it seems all of a sudden, neither can connect to the other. CrashPlan seems to be running fine in the dockers, but they both say the other person is offline. Both are upgraded to 4.4.1. Both of us can use the GUI in the CP-Desktop docker. Neither of us has changed routers or router settings, so can't think of any new firewall issues. Temporally, it seems the problem started the same time as 4.4.1 came out (and I coincidentally upgraded my workstation to Windows 10, but I can't see how that would affect CP on the unRAID server). Anyone have ideas? Thanks in advance. - TD
  6. Could this be a problem of crashplan being launched before the destination drive is mounted? How are you running crashplan - plugin or docker. Is it being launched automatically at system startup? I thought about that, so I tried stopping CrashPlan docker, not auto-starting it, and then manually starting it after booting with Unassigned Devices mounting the disk. That still didn't work.
  7. tigerdoc

    [CONTAINER] CrashPlan & CrashPlan-Desktop

    Barakthecat, how is this still working out for you. I'm interested in setting this up with a buddy but wanted to get more details. Basically just how hard was it? Any tips / tricks? I'm assuming you need static IPs? or does crashplan.com facilitate that even in the free version? Thanks in advance. I'm the other half of Barakthecat's CP setup. Working fine (aside from my messing up his backup disk by changing the way I mounted it, but that's fixed). No static IP needed. I didn't even have to open any ports on my router's firewall.
  8. tigerdoc

    [CONTAINER] CrashPlan & CrashPlan-Desktop

    [Apologies for cross-post between the two associated features.] Curious if anyone else has found this issue: I had been using SNAP to mount a disk outside of my array onto which I put my friend's CrashPlan backup. Was working fine for many months. So of course I decide to change from SNAP to Unassigned Devices. It seemed to mount perfectly fine to /mnt/disks/CP_[friend_name] and I could see the file system via terminal. I had the docker container map the volume as it had been, from /mnt/disks/CP_[friend_name] to /CP_[friend_name]. But when CrashPlan tried to back up to it, it ran out of space, which made no sense since it's a 4 TB disk with initially 2 TB of data on it (and then 0 data on it when I wiped the file system and put on a new one). It looked like CrashPlan was writing to the docker container file system, to a folder it made called disks/CP_[friend_name]. Of course it ran out of space after about 2.5 GB since I'm pretty sure it hit the docker image limit. Here's where it gets interesting. When I stopped using Unassigned Devices to mount it and instead just mounted it manually in the go file, CrashPlan worked fine and used the disk like it should. Anyway, anyone else have experience using Unassigned Devices to mount a disk outside of the array for use as a CrashPlan destination? Thanks, TD
  9. [Apologies for cross-post between the two associated features.] Curious if anyone else has found this issue: I had been using SNAP to mount a disk outside of my array onto which I put my friend's CrashPlan backup. Was working fine for many months. So of course I decide to change from SNAP to Unassigned Devices. It seemed to mount perfectly fine to /mnt/disks/CP_[friend_name] and I could see the file system via terminal. I had the docker container map the volume as it had been, from /mnt/disks/CP_[friend_name] to /CP_[friend_name]. But when CrashPlan tried to back up to it, it ran out of space, which made no sense since it's a 4 TB disk with initially 2 TB of data on it (and then 0 data on it when I wiped the file system and put on a new one). It looked like CrashPlan was writing to the docker container file system, to a folder it made called disks/CP_[friend_name]. Of course it ran out of space after about 2.5 GB since I'm pretty sure it hit the docker image limit. Here's where it gets interesting. When I stopped using Unassigned Devices to mount it and instead just mounted it manually in the go file, CrashPlan worked fine and used the disk like it should. Anyway, anyone else have experience using Unassigned Devices to mount a disk outside of the array for use as a CrashPlan destination? Thanks, TD
  10. tigerdoc

    [CONTAINER] CrashPlan & CrashPlan-Desktop

    Ah, Windows Remote Desktop. Genius. Thanks. - TD
  11. tigerdoc

    [CONTAINER] CrashPlan & CrashPlan-Desktop

    Thanks, Opentoe. What do you mean by "RDP"? I have tried using NoMachine for a desktop connection, but it has failed to connect. - TD
  12. tigerdoc

    [CONTAINER] CrashPlan & CrashPlan-Desktop

    Yes, I have both installed, and I have been using CP without the GUI Docker for a while without difficulties. Just curious if it would be more convenient not to have to use the Windows client to connect to the unRAID engine. (I can connect to the unRAID CP engine from a Windows system as usual.)
  13. tigerdoc

    [CONTAINER] CrashPlan & CrashPlan-Desktop

    I'm probably missing something obvious here, but once the GUI Docker is installed and running, how do I use it? Thanks! - TD
  14. This one just bit me the other day as we are no longer able to have the docker.img reside on a user share. Adding it to a cache the way listed in the directions essentially creates a share on the cache drive that isn't marked as cache only, resulting in the mover moving the docker.img to disk1, which will causer docker to fail upon reboot. Simpler to just put docker.img at /mnt/cache/docker.img then it won't be in a share at all and won't get moved. Are we sure that an individual file in /mnt/cache won't get moved too?
  15. tigerdoc

    Unable to create new Docker image

    Not sure if that did it, or the reformat of the cache disk, but now I can create a new docker image. Odd that it wouldn't have taken the size already specified in the field, though. Thanks.

Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.