brainbone

Thanks, all, for confirming that I can use xfs on the cache. I do like the idea of btrfs, but the apparent reality scares me a bit. Thinking more about the issues with unclean shutdowns, is there any known reason why this could be happening? Is unraid using btrfs without barriers? Does this issue only occur on drives without power loss protection? etc.

There seems to be a general consensus here that btrfs doesn't handle power loss well. Seems people often loose much of the data on their cache drive(s) if power is cut to the system. Even though I'll be running with a UPS, from my point of view, total data loss of the "cache" (which is used for far more than just cache in unraid) from a simple power failure is simply unacceptable. It is not uncommon at all for a UPS to fail just at the moment you need it. What can be done to make the cache drives more resilient in the case of power loss? Can the cache be run with XFS or EXT4?

You could fork it, modify your fork, and do a pull request for that modification and see if gfjardim will merge it. That, or someone else could fork it, and everyone could start using that fork instead -- but I don't believe github allows multiple maintainers for an individual repository, and there are obvious issues with sharing credentials for a single github user account. It'd be great if a version could be created that: 1 - Allows the password for the "ubuntu" user account to be changed via an environment variable instead of having it hard-coded to "PASSWD". 2 - Changes "ubuntu" user account name to something else, like "crashplan" -- or allow it to be changed via environment variable as well. 3 - Allows the URL of the CrashPlan installation package to be modified via environment variable (best if environment variable is empty to use a hard-coded default, else use value of environment variable.) 4 - Allows XRDP installation/configuration to be optionally disabled, again via environment variable, enabling a "headless" mode. (see #5 for why) 5 - Last, but certainly not least, combines CrashPlan and CrashPlan Desktop into one container, allowing both the engine and UI to automatically update. Once that's done, it probably wouldn't be a huge issue if the repository owner didn't get around to updating it immediately.

It's in the folder you have mapped for /config in your CrashPlan volume mappings. For me it's /mnt/disk1/docker/appdata/crashplan/config I don't export my appdata folders, so while still SSHed into my unraid server, but disconnected from the CrashPlan bash (after the first "exit"), I just edit directly using the command: nano /mnt/disk1/docker/appdata/crashplan/config/id/.ui_info But for you, the "/mnt/disk1/docker/appdata/crashplan" portion will be different, depending on what you have entered in your volume mappings. Probably somewhere on your cache drive, if you have one.

Thanks, I'm a bit new to Docker -- still wrapping my head around it. (And your crashplan desktop update is working perfectly. Thanks again.) Edit: It seems the issue with the Crashplan desktop not being updated is related to Crashplan being run headless. For those that want to run Crashplan Desktop, is there any benefit to having separate containers for the desktop app and the engine that outweigh this update issue?

I'd like to change the password for CrashPlan-Desktop from PASSWD to something else. Will this change stick? Any issues with doing this?

Thanks for that. Will these changes complicate application of the "real" docker update when/if that comes?

This assumes I have a windows client.

Though no way to backup data to your crashplan account...

I thought crashplan clients auto updated? Just installed crashplan desktop and I'm getting the "disconnected from backup engine" error. Damn. Really wanted this to work... Any other quick and easy alternatives?

Nevermind. bad CMOS battery. Lost time between power cycles.

Followed the instructions and purchased a new plus key using the WebGUI on a new unraid server, but getting "ERROR (5)" pasting the supplied key url and hitting "Install key".

Nevermind. Used Fat32format to format the flash drive as Fat32. Since make_bootable.bat worked with NTFS, figured unraid would as well. Seems to be working with fat32.

I'm setting up a new Unraid 6 machine -- plan to get a pro license for it. I've formatted a Sandisk "Ultra" 64GB USB 3.0 flash drive (On Windows 8.1, using NTFS, makeboot didn't like exFAT), and have booted the machine. Seems to boot up alright. I can connect and log in via telnet and SSH, but when I try to access the web gui using either the default "tower", or the IP address of the machine, I get a "connection refused" in chrome or a "Unable to connect" in firefox. Help??