Leifgg

I can’t see any obvious reason but it might be that you are running out of memory. Suggest having a look in the service.log (the latest one) and search for OutOfMemoryError. You can find the log files in the log folder for CrashPlan in your appdata share.

Older releases (than 1.0) is no longer supported and has been removed from the file archive. Read more at the Plex Forum: http://forums.plex.tv/discussion/62832/plex-media-server#latest

There are several reports about issues with watched status at the Plex forum. Some clients works fine but a few have this issue.

According to Plex Release Announcement: Plex Media Server 1.0.0 is now available for everyone

Actually, sqlite3 is already installed in the same folder as the database (I was at the office when I responded so I couldn’t check). Happy you got it resolved

The database is located in the Plex config folders (appdata), not inside the container. I am not a Linux expert but I would guess that you need to locate sqlite3 first, then run it with the path to the database (for your installation) and the UPDATE command. Make sure to stop the Plex container first as well.

I would humbly suggest that the first post in this thread be updated with the above information. The current information mentions the /config and /mnt volumes (only the former seems to exist) with nothing on the others. I did not feel comfortable even starting the container until I ran across this post that describes each of the volumes. Thank you, Leifgg! Interesting, I didn't realize those default paths had been added to the XML. I'll suggest some updated text for the OP to gfjardim. I did a fresh install and the default mappings are actually slightly different: /config <-> /mnt/user/appdata/CrashPlan /mnt/user <-> /mnt/user /unassigned <-> /mnt/disks/ /backup <-> /mnt/user/Backup/ The settings for the CrashPlan container includes some help explaining each mapping as well.

I am guessing, I only do backups to the CrashPlan cloud so I am unable to verify if local backups are visible for the mobile app.

We probably need a little more information on what you actually did. I assume that you just installed the CrashPlan container with the default folder mappings. In the CrashPlan app you first need to select what files to backup (the Backup tab, Files section and From then Change and select the folders/files). Next step is to select Destinations. What did you select there? Haven’t used the mobile app for a while but I assume that it will only see files that has been stored at CrashPlan Central, not local Folders. Does the History show that it actually did a backup?

It has been deprecated since the CrashPlan container now contains a GUI as well. Check the first post in the CrashPlan thread.

There is a plugin called Dynamix Cache Directories that might be useful to install. It will keep the folder information in memory so that CrashPlan doesn’t need to scan the disks. It will use some of your memory and it needs to be configured to fit your system. When you have installed it go to the setting for the plugin and enable Help in the unRAID banner. I am not 100% sure that it is CrashPlan causing your disks to spin up. If you have installed CrashPlan on a cache drive it shouldn’t write anything to the array (and keep your parity disk spinning). If you haven’t, then it will for sure keep your drives spinning (including the parity drive) since CrashPlan basically writes everything (more or less) to log files.

If you have a backup of the appdata folder it’s easy to recreate any docker app you have. You only need to select Add Container and select template from the drop down list and look for User defined templates. These templates contain all your settings for the container you have used so a new container will be created based on that. If you have lost your docker.img file that needs to be created first as well. If you don’t have a backup of the appdata folder available, you can still use this method but you would need reconfigure each docker app. For CrashPlan it would be like setting up your account again, select folders to backup and probably adopt (import) your current backup data.

The only downside to backing up your flash drive is that restoring the super.dat file will trigger a parity check, right? Seems like a small price to pay to have a full backup of all your settings. This is covered in the OP. Agree! Take the array of line, make a local copy of the USB stick, start the array and put a copy there as well and let CrashPlan back it up.

The CrashPlan app is running in a Linux container and all these folders you can see belongs to that Linux OS expect for the mappings you made.

I will try to explain: /config >> /mnt/cache/appdata/crashplan/ CrashPlan needs some place to store configuration files and logs. What the CrashPlan app can see is /config and in the example that place is located at /mnt/cache/appdata/crashplan/ and this assumes that you have a cache disk. The default location for Docker app configuration files is /mnt/cache/appdata/name_of_the_app Note that the share appdata (a top level folder) needs to be set to “Use cache disk: Only” If you don’t have a cache disk you need store the config files in a user share on your array. Mappings could look like this /config >> /mnt/user/appdata/crashplan/ /UNRAID >> /mnt/user In the CrashPlan app you will see /UNRAID and you select the user shares to backup and these are located at /mnt/user . Note that this assumes you are using user shares, not disk shares. /unassigned >> /mnt/disks This one is used if you are using disks or shares mounted by the plugin Unassigned Devices. This could for example be an USB disk or a share on another server. /backup >> /mnt/user/Backup/ This one is probably intended to be used for local backups (not to the CrashPlan cloud). /flash >> /boot I guess you added this one to be able to back up your USB stick with the unRAID OS? That’s not actually a good idea. When you back up the USB stick your array should be stopped. Best way to do this is to stop the array and make a copy and store locally on your PC. This can be done by using the file explorer in Windows (if you are using Windows...) \\your_server_name\flash

Working as usual on my system (6.2.0-beta 18).

It could be that the folder mappings for the container are incorrect. Another reason is the fact that you are using the plugin Unassigned Devices to connect to a remote server. When you start your server the Docker containers (and CrashPlan) are started before the plugin Unassigned Devices has been started and mounted the remote server. This makes your remote server invisible for CrashPlan. Go to Main (unRAID GUI) and Unassigned Devices and click on the Mount point entry and make sure that you can see the folder on the remote server and its content. If that works, use the CrashPlan GUI and select Destinations and browse for the destination folder and see if you can see it here as well. It would be useful to see your folder mappings for CrashPlan. I have included the settings for my configuration.

I newer got that working on the Linux version but it will when using Windows.

Cool! Keeping fingers crossed… And for others that might be interested: The memory settings is in the file run.conf in the bin folder. Use a Linux friendly editor and change the first line. 1024m is the default 1 GByte, increase as needed (2048m is 2 GByte) SRV_JAVA_OPTS="-Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx1024m

Strange! Could be running out of memory? Have you changed the memory allocation in CrashPlan from the default 1024 MB? Also found a link about permission problems: http://econdataresearch.blogspot.se/2015/01/resolving-issue-with-crashplan-keep.html Edit: One more thing to check is the latest service.log in the log folder and look for ERROR or OutOfMemoryError

If you already have a lot of data stored at CrashPlan all new data will be compared with what you already have stored. This is the data deduplication process; it compares all blocks that you backup with all “old” data.

Only thing I can think of is that you already have made a backup of these files previously. The behavior sounds a bit like the process when you move CrashPlan to a new computer and need to adopt your old backup to a new setup. Check the Network graph in the unRAID GUI to see how much bandwidth you are using.

All looking good now (Dynamix temp uninstalled as well). Many thanks!

Again, many thanks gfjardim! This is really an awesome update, a simple and clean setup that should get anybody up and running CrashPlan within no time at all.

Both containers are still there and working. An Ubuntu VM works fine as well but I haven't got real time file monitoring working so it only finds new files during a scan (that I have set to once per day).