CrashPlan on FreeNAS using Iohyve

The better way to run CrashPlan on your FreeNAS…

With the 9.10 version of FreeNAS, comes a better way to virtualize functionality on your FreeNAS server. It also allows us to move away from the headaches we have seen with the Jails, particularly with the CrashPlan. The CrashPlan jail has required too many hours of tinkering with every upgrade, and after seeing everything break with the release of CrashPlan version 4.8, I decided there must be a better way to back up my data on my NAS.

The solution resides with Iohyve – a built in hypervisor that allows you to run virtual machines.

The first step is to ssh into your FreeNAS installation and identify the zpool you wish to install your virtual machine on – I have added a separate pool running on an SSD disk within my environment, and named the SSD storage zpool “SSD”.

zpool list



Identify the correct zpool name in your environment.

Next, run the setup of iohyve on your identified zpool:

iohyve setup pool=SSD



You also need to identify the correct interface, to bridge your VM to:


Once identified, set the interface to bridge your VM to, and set the correct kernel module to load:

iohyve setup net=alc0 kmod=1


Now create the ubuntu host (named ubuntu_crashplan), allocating 20GB of disk space:

iohyve create ubuntu_crashplan 20G SSD



Next we need to set the correct parameters for Ubuntu, first allowing to boot with grub, set the OS as debian based, configure the RAM, CPU count, and the con parameter (adjust RAM and CPU as needed):

iohyve set ubuntu_crashplan loader=grub-bhyve os=debian ram=1024M cpu=1 con=nmdm1



Now we need to fetch the ISO to install (or copy the link to your preferred version of ubuntu):

iohyve fetchiso

Then install the ISO image

iohyve install ubuntu_crashplan ubuntu-16.04.1-server-amd64.iso


Give the installer a minute to start, then open up a second SSH session to your FreeNAS, and run the console command to connect to the new virtual machine:

iohyve console ubuntu_crashplan


Step through the installer as normal, but once you arrive to the software selection screen of the installer, you may choose “OpenSSH server” to allow direct access to the virtual machine.

Once the installer completes, reboot the new virtual machine.

 Verify the status:

iohyve list

Start the virtual machine:

iohyve start ubuntu_crashplan

Set a static IP if you prefer, or set a DHCP reservation within your firewall. Then either SSH into your new ubuntu server or use the “iohyve console ubuntu_crashplan” command to gain access.

We have several considerations, before implementing CrashPlain:

  1. What paths do we want to mount?
  2. What file system do we use to mount these paths?

In my environment, I will be making the following mounts, with the mkdir command:





We will then need to mount the appropriate folder to be backed up on the FreeNAS to the created mount points.

Example mounts of shares using CIFS

In my example, I am going to use CIFS and a separate service account to mount to the share:

sudo apt-get update

sudo apt-get install cifs-utils

Create a samba user:

sudo nano /etc/samba/user

Create (2) lines in the credentials file (I created an account with read-only permissions within FreeNAS for the SMB share)



Use “control+o” to write the file, and “control+x” to exit from Nano.

Set the new user file to read only:

sudo chmod 0400 /etc/samba/user

Backup your fstab file:

sudo cp /etc/fstab /etc/fstab.bak

Edit your fstab file:

sudo nano /etc/fstab

We will need to add the various mount points on your FreeNAS with their associated path on your CrashPlan server. Please note that if you have a share name with a space, you must substitute the space with “\040” in your fstab file. For example:

//\040Videos/ /mnt/Music_Videos/ cifs crednetials=/etc/samba/user,noexec 0 0


Suggestion: You will want to map out a restore folder to your NAS. That will direct downloaded files to your NAS instead of the 20GB virtual machine disk. For example, I created a /mnt/Restore directory on the CrashPlan VM that maps to a Downloads folder on my NAS.

Enter your mount points and mappings, and reboot your server to test. Once everything is mapped out correctly, you can install CrashPlan:

cd /tmp/


tar -xzf CrashPlan_4.8.0_Linux.tgz

cd /crashplan-install/

sudo ./

Now we should be prompted with the CrashPlan installer. Use the defaults, except for the incoming backup data. I created a /mnt/Restore mapping in my example:


Once completed, some useful information:


Headless Setup:

Allow the server to listen to external connections:

sudo nano /usr/local/crashplan/conf/my.service.xml

Identify and change from:




Copy the key from your Headless CrashPlan .ui_info file, and double checking the listening port:

cat /var/lib/crashplan/.ui_info

Into your local .ui_info on your computer.

This varies by operating system, so please refer to CrashPlan’s site for the file locations at:

Once done, your client will have a .ui_info file that shows the correct port, the correct key, and the IP of the new virtual server. The virtual (and headless) server’s .ui_info will show the IP as after we configure the file.

Complimentary .ui_info files – client on the left, server on the right:


Once these are in agreement, restart the crashplan service on the virtual server:

sudo service crashplan restart

Launch the local application from your machine with the correct .ui_info, and you should attach!



With this replacing a previous CrashPlan Jail, I simply adopted this computer after the login to replace my previous setup. All mount points were named to replicate the setup in the replaced FreeNAS jail.

Once you have connectivity between your client and your host, you can lock each .ui_info file with the immutable bit. For the Ubuntu Crashplan server, use:

sudo chattr +i  /var/lib/crashplan/.ui_info

For OS X, use:

sudo chflags nouchg /Library/Application\ Support/CrashPlan/.ui_info

This will lock both files, and prevent edits. To unlock the files, change the chattr attribute to “-i” (instead of +i) and the chflags attribute from “nouchg” to “uchg”.


Local Administrator Password Solution (LAPS)

LAPS (Local Administrator Password Solution) is the recommended security solution to mitigate PtH (Pass the Hash) attacks of a local administrator account on your network.

Local administrator accounts are a bane to network administrators. Physical access can compromise the local account, and it is typically standardized across the domain as a secondary tool for the help desk and administrators when computers lose trust with their respective domain controllers. A compromised local administrator account has the potential to create havoc across your network.

LAPS can provide your environment with a local administrator password that is unique for each workstation, and provide basic password management, with manageable length, complexity, and age requirements based on your group policy. You can also determine what security groups are able to retrieve these passwords through a component (the Fat Client UI). This is discussed in more detail in the Microsoft Security Advisory 3062591:

The installation of LAPS comprises of the following steps:

  1. Download and install components on the management server
  2. Update the active directory Schema
  3. Set the permissions for viewing the local administrator password
  4. Push the client install component to the managed computers
  5. Set the group policies for LAPS
  6. Retrieving the password


Download and install components on the management server

The LAPS components can be downloaded from Microsoft at the following site:

There is both a 32 bit and a 64 bit msi that may be downloaded for your environment. We will create a GPO to deploy both based on the architecture later in the article.

In this article, the installation of the LAPS management components will be installed on a Windows Server 2012R2 Domain Controller.

Install LAPS
Install LAPS









Select all of the components, and complete the installation on your management server.


Update the Active Directory Schema

The management tools installed the PowerShell module on your management server. Run PowerShell as an administrator with an account that is a member of the built-in Schema Admins group.

Import the module within the PowerShell prompt:

Import-Module AdmPwd.PS

Then update your schema with the following commandlet:












Set the permissions for viewing the local administrator password

We will use ADSIEdit to manage the permissions on who is able to view the new attribute created.

Open ADSIEdit, the right click ADSI Edit and “connect to”










Then choose the “Default naming context”:






You will now need to drill down through your OU’s to the correct container the computers to be managed. Right-click on the OU, and select “Properties”. Choose the “Security” tab and click on the “Advanced” button.











You now need to audit the accounts within the advanced security settings, ensuring that non-administrative accounts do not have the “All extended rights” permission. This is to be UNCHECKED.









Set the permissions for viewing the local administrator password

Next we need to allow the computers in are specific OU(s) the ability to update their password attributes, via the AdmPwdComputerSelfPermission PowerShell commandlet, specifying the correct distinguished name for each OU:

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=SBSComputers, DC=infosoda, DC=local"

Hint: Right click on the OU, select “Properties”, choose the “Attribute Editor” tab, then “View” the distinguishedName to copy the correct distinguished name for your OU.

We then set the permissions per OU to the security groups that are allowed to retrieve the password set by LAPS using the AdmPwdReadPasswordPermission PowerShell commandlet, specifying the correct distinguished name for the OU and the correct security group:

Set-AdmPwdReadPasswordPermission -Orgunit "OU=SBSComputers, DC=infosoda, DC=local" -AllowedPrincipals "Help Desk Support"

In the above example, members of the security group “Help Desk Support” can retrieve passwords for all computers within the SBSComputers OU. Repeat this step as necessary to ensure that the correct groups have access to the correct OUs.


Push the client install component to the managed computers

We can now create a policy to push either the x64 or the x86 client out to the machines, based on their architecture. Create a folder in your netlogon directory, and drop both the LAPSx64 and the LAPSx86 msi’s that we downloaded earlier into the new folder:






Now open up Group Policy Management, create a new group policy object named appropriately, end edit the new policy.

Computer Configuration -> Policies -> Software Settings -> Software Installation -> New -> Package

When creating the x86 installer, uncheck the “Make this 32-bit X86 application available to Win64 Machines






Assign the policy to the correct OU’s to allow policy to push out the MSI to the computers. Once installed, “Local Administrator Password Solution” will appear as an installed application under “Programs and Features”.


Set the group policies for LAPS

Utilizing either the same Group Policy, or a separate policy, you now need to implement your settings for LAPS. These settings are located at:

Computer Configuration -> Policies -> Administrative Templates: Policy Definitions -> LAPS

There will typically be (3) settings to enable:

  • Password Settings
  • Do not allow password expiration time longer than required by policy
  • Enable local admin password management







Password Settings (ENABLED): Choose password complexity, password length, and password age, recommended settings:

  • Password complexity: Large letters + small letters +numbers + specials
  • Password length: 20 characters
  • Password age (days): 30 days

Do not allow password expiration time longer than required by policy (ENABLED)

Enable local admin password management (ENABLED)

Link the policy to the correct OU’s if it is a separate policy, and allow the policy to deploy to the environment.


Retrieving the password:

The easiest way to retrieve a password configured by LAPS is to fire up the LAPS UI application installed on your management server. Launch the LAPS UI application, type in the computer name, and the application will retrieve the password and the current expiration date. By enabling “Advanced Features” within Active Directory Users & Computers (View -> Advanced Features), you can also view the Attribute Editor tab, and the specific attribute “ms-Mcs-AdmPwd” to retrieve the password:








Deploying LAPS is a great way to add an additional layer of security to your environment. It also allows administrators the ability to easily manage and create local administrator policies for your environment.