unRAID: Storing Containers, Appdata and VMs on an Unassigned Device
By far, the most common configuration for unRAID users is to store their docker containers, appdata, and VM data on the Cache drive, which is typically an SSD. However, storing it on a separate SSD mounted with the CA (Community Applications) plugin: Unassigned Devices, can alleviate some issues. When writing large amounts of data to the cache, you can saturate the I/O of the drive, causing applications to perform poorly, or not at all. However, with the data on a separate drive, your apps and VMs are left unaffected by the Cache drive reads and writes.
There are a few steps in order to move your appdata off of the cache drive. First, you need an empty SSD installed in the system. The size you need depends on your usage (how many containers, and VMs, as well as some appdata folders such as Plex’s metadata can get quite large). A 120GB SSD would be the absolute smallest recommended, and a 256GB or 512GB SSD should be plenty for most use cases.
To be safe, it is recommended to create a backup of your appdata before starting any sort of transfer. The CA Appdata Backup/Restore plugin will handle that for you. Once that is complete, you will need to install the Unassigned Devices plugin. For help with any of these, see this video series by Spaceinvader One: https://youtu.be/su2miwZNuaU
Once you have CA Unassigned Devices installed, head to Settings -> Unassigned Devices, and change “Destructive Mode” to “Enabled”. Then head back to the Main tab in unRAID and scroll down to the Unassigned Devices section. You should see your SSD listed there, with an orange “Format” button beside it. Format the drive (btrfs is the recommended file system), then mount it. If you click the white icon to the left of the drive, you’ll see the partition below it. You can rename the partition to make navigating via the command line easier (in this guide we’ll use ua_appdata).
Note: It’s best practice to stop all docker containers, and VMs before proceeding, however, you can perform this without doing so, you may however lose some changes that occur while the process is running. Do so at your own risk.
In unRAID, head to Settings -> Docker, set “Enabled” to “No” and click apply. Then go to Settings -> VM Manager and do the same.
Before we begin copying, we need to create some directories. Open unRAID’s Terminal and run the following commands:
$ cd /mnt/disks/ua_appdata $ mkdir system $ mkdir isos
Now we’re ready to copy the data. Again, in the terminal, run these commands:
$ cp -ar /mnt/user/appdata /mnt/disks/ua_appdata $ cp -ar /mnt/user/system/libvirt /mnt/disks/ua_appdata/system $ cp -ar /mnt/user/system/docker /mnt/disks/ua_appdata/docker
Once the operations complete, the final step is configuring the system to use the new file locations.
Under Settings -> Docker, change the Docker vDisk location to:
and the Default appdata storage location to:
Then change Enable Docker to Yes and apply.
Under Settings -> VM Manager change Libvirt storage location to “/mnt/disks/ua_appdata/system/libvirt.img”
and Default VM storage path to
Then change “Enable VMs” to Yes and apply.
On the Docker page in Unraid, you’ll need to go through each container, and manually reassign its appdata location. Click the container and choose Edit. On the edit screen toggle Advanced View on in the top right corner. Some containers hide the appdata location below the “Show more settings…” at the bottom. You’ll also need to change any other fields that reference appdata (one instance is the /logs path mapping in Tautulli). Additionally, any path referencing an unassigned device needs to have its access mode changed to “R/W Slave”. To do this, click Edit beside the path and change “Read/Write” to “R/W Slave”. As an additional note, there are some containers that do not have an appdata path.
Start your containers if they were not already started, and keep an eye on logs for any potential problems. It is recommended that you keep the old appdata folder around for a bit to ensure all the containers are using the new location. To check this, open terminal and issue these commands:
$ cd /mnt/user/appdata $ ls -lah
Look for directories that have been accessed after the time & date that you instructed the container to use the new location. Once satisfied that all containers are correctly configured, you can safely delete all of the data in “/mnt/user/appdata” and the share itself from within unraid.
To see if you missed changing any of the path mappings to R/W Slave, run the Fix Common Problems plugin. It will issue an error message if a path is set to the incorrect access mode.
Now enjoy application performance that’s unhindered by intensive cache activity and practically non-existent IOWait. If you have any questions or trouble, feel free to stop by the discord for help.