SOLVED Upgrade to 9.3 - CrashPlan permissions - incoming backup location not accessible

[kavefish]

Greetings all,

I've been pulling my hair out over this for the last couple of days since I installed 9.3, and figured asking for assistance is my next step. Hopefully it's something simple that I'm just not doing correctly!

I ended up having to do a new installation of 9.3 since the upgrade from 9.2.1.9 failed. I don't have a super complex configuration, so I figured it shouldn't be too bad or difficult to start over again, jails included. Fortunately, the pool import worked beautifully and I didn't lose any of my data! I am, however, having a problem with getting the permissions setup correctly for CrashPlan to allow me to receive backups from other machines I own. It worked great on 9.2.X, so I'm sure there's no reason I can't get it working in 9.3.

After importing the volumes and getting my main data stores back, I decided to blow out the old jails data sets that remained from my 9.2 installation so I could start anew. No problem. I was also able to install the CrashPlan plugin with no issues. Pictured below is my volume list. I have a "Backup" dataset that I use to store CrashPlan backups, TimeMachine backups, and backups from an imaging software I have been evaluating called ShadowProtect.

When I started having issues with CrashPlan not working, I cleared out the CrashPlan data set and recreated it, thinking the permissions from the import got a little hosed. Permissions for the CrashPlan data set are now set to root/wheel, and I even set everything to 777 to try to give the jail access to the data set. Eventually I will tune these permissions down once everything is working.

I created a couple of storage shares for the CrashPlan jail. One is '/media/backupFROMnas' to indicate data going out to CrashPlan's servers, and '/media/backupTOnas' for my other CrashPlan machines to store backup sets on my NAS.

Permissions to the storage shares from within the CrashPlan jail. The owner/group is root/wheel:

I kept the permissions of the CrashPlan data set as root/wheel because the CrashPlan process within the jail runs as root. I know other plugins often create non-root accounts to run as, but that doesn't seem to be the case here.

Inside the CrashPlan client (I mapped my GUI to the headless client running in the jail via SSH), I am able to select the storage share to backup my NAS data to CrashPlan's servers (/media/backupFROMnas), and it works well. It's going to take a couple of days to finish comparing data on the servers to the data on the NAS, but at least I don't have to upload 1.6TB again at 5 Mbit/sec! For the inbound backup (storage share /media/backupTOnas), I receive the error "Backup disabled - backup location is not accessible"

Under the inbound backup settings, I am pointing CrashPlan to /media/backupTOnas. The test and test1 folders are folders that I created from within the CrashPlan jail to see if I had permissions to write to the storage share. I do have permissions as root within the jail to read/write/delete data in this folder. CrashPlan doesn't think it does.

At this point, I'm not sure what to pursue next. I don't know if it's possible to run CrashPlan as a different user, and then let me create a matching user/group account in the main FreeNAS. But I figured with user/group of root/wheel in the jail matching root/wheel account in FreeNAS, that doing so probably wouldn't make much of a difference. Plus I have the permissions wide open in the CrashPlan data set.

Has anyone else seen this error, or have had a similar problem?

Thanks for taking the time to read this, and I appreciate any feedback or guidance on how I may further troubleshoot and resolve this issue.

- William

 

[Pasquale61]

Just curious if you already had any data in the /mnt/XenonNAS/Backup/CrashPlan dataset before you changed those permissions. I noticed you didn't check "Set permission recursively." I'm just taking a wild guess here. I already tested outbound from 9.3, but I will try inbound today and see if I get the same results you are getting.

This really interests me as I'm getting ready to do almost exactly what you're doing. The only difference is that I'm going to be attempting to use CrashPlan's "Adopt a Computer" method to move everything (in/out) from a Windows 7 PC to my FreeNAS. That should be interesting since I too have about 1.5TB stored on CrashPlan's servers and don't want to resend everything. I also have about 2TB of inbound backups that I want to move to my FreeNAS.

 

[kavefish]

Hi Pasquale61,

Thanks for the reply. I originally had some data from incoming backups in the /mnt/XenonNAS/Backup/CrashPlan dataset from my previous installation of 9.2.1.9 along with CrashPlan running in a jail. I was hoping that I could "resume" the incoming backups just as you do when you re-install CrashPlan and want to adopt an existing backup. Unfortunately I couldn't get CrashPlan in 9.3 to write to the aforementioned dataset (giving the "Backup disabled - backup location is not accessible" error). I figured something was wrong with the permissions, so I completely erased the CrashPlan dataset and started fresh.

The "Set permission recursively" was checked originally when I pushed down root/wheel and 777 permissions. I guess it unchecked itself when I went back into the permissions page to take the screenshot.

I also experimented a little more this morning. I pointed the "incoming backup" folder to a folder internal to the CrashPlan jail, and after restarting the CrashPlan engine I still am getting the same error ("Backup disabled - backup location is not accessible"). Am thinking about installing CrashPlan manually in a linux jail, and see if it's possibly an issue with the specific version of CrashPlan included in the plugin. Installed VirtualBox and Debian. Now to just figure out how to map a NAS folder to Debian!

 

[Pasquale61]

I just tried an inbound test from scratch and it worked for me. I followed this to create my crashplan ID and get the UI working: https://github.com/sirkkalap/freenas-crashplan-howto

When I created my crashplan dataset, I selected Windows instead of Unix for Permission Type and left it at default. Not sure if that has anything to do with it, but I noticed that's one difference. The other thing is that when I followed the above procedure for the UI, it had me add (invite) the wheel group to the crashplan ID. I don't think this has anything to do with the backups, but I'm not sure.

 

[kavefish]

I appreciate you trying out the inbound backups, and I'm glad you got it to work.

I tried following the guide, but still was getting the same errors. Then I tried the simplest thing, and it worked. On each of the clients that I was backing up to my NAS, I had to 'remove' and 'add' the NAS as a new destination. Once I did that things started working beautifully! There's good and bad to this. About 3 TB is scheduled to backup via my local network. I have about 1.5 TB of data on remote machines that will have to be re-uploaded to my NAS. That will take a couple of months. Fortunately I have other copies of the data, and am glad my ISP doesn't fuss at me for using lots of data!

Thanks for the troubleshooting tips and hope that this solution will help others who may have experienced a similar problem after upgrading their FreeNAS. Thread marked as SOLVED!

- William

 

[Pasquale61]

I think I misunderstood how incoming CrashPlan backups work in a jail. I just figured out that on my system my incoming backups are actually not being stored in the storage I added to the jail. (using your example above: /media/backupTOnas) The incoming backups are actually stored in the jail at /usr/pbi/crashplan-amd64/share/crashplan/backupArchives. It looks like the /media/backupTOnas folder I added is only used if I select it as a backup destination for backups on my FreeNAS. Is this how yours is working, or did I setup something wrong? Sorry, I've been a longtime CrashPlan user in Windows and I'm just trying to understand out how it works here.

Thanks!

 

[kavefish]

Hi Pasquale,

It has always been my preference to get the data from the inbound backups away from inside of the jail into a dedicated CrashPlan dataset I created, and shared through the jail storage /media/backupTOnas. My thoughts were that this methodology will prevent a massive 1+TB jail folder, and that the data might be safer if the jail were to somehow become corrupt. I have seen the occasional posts on here where an update to CrashPlan would cause the engine to stop working in the jail, or the entire jail becoming corrupt. I don't have any specific links to support this. Jails have, for the most part, been very reliable for me (except for when I goof them up), so to protect my data from me (or any other jail mishap) I tend to move all my data away from the jail. It's the same reason why my DLNA server runs inside a jail but serves data from a dataset in the NAS (/mnt/NAS/media).

To change the destination of the inbound backups, in the main CrashPlan window, click on Settings. In the General tab, click Configure next to 'Inbound backup from other computers.' In this setting menu at the bottom, you have the opportunity to change the default archive backup location. It is here where I changed the default folder to a shared jail storage folder to point the data away from my jail, in my case '/media/backupTOnas' pointing to /mnt/NAS/Backup/CrashPlan.

Please let me know if you have any other questions! This is my first CrashPlan installation away from Windows and Mac, and especially with running CrashPlan in a headless, isolated container. It's very much still a learning process for me too! I'm always interested in learning how others manage CrashPlan backups.

- William

 

[Pasquale61]

Hi Kavefish,

Thanks for helping clear this up! This was really helpful.

I set my original CrashPlan up on my Windows system 3 years ago with 5 incoming backups and it pretty much ran in what I like to call "set-it and forget-it" mode. (One of the reasons I love CrashPlan.) I forgot about the "Inbound Backup Setting." I don't know what I was thinking, but I thought this was the same as selecting the "Folder" tab under "Destination." I think that's just a local repository for outbound backups "from" my FreeNAS.

So anyway, regarding my Windows-->FreeNAS CP migration, I copied all my backups from my local Windows inbound backup folder to my FreeNAS inbound folder, and then pointed my jail to it like you described above. The really cool part is that after I did all of this, I logged into my account on CrashPlan's website, and selected each of my remote computers and added my FreeNAS CrashPlan as an additional backup destination. So, without touching any my remote computers, they automatically started making an additional backup to my FreeNAS. Since all the folders were already there, hardly anything transferred over the network and they were done extremely quick.

I'll let it run for a couple of weeks like this before I remove the Windows destination from my remote computers. When I do that, it completely deletes them from my Windows repository. (I still have the cloud backups too...but that's a last resort for restores.)

Thanks again!