After getting Plex plug-in up and running, I started researching the FreeNAS features for hosting other code. I plan to keep my FreeNAS box up and running at all times, as is typical NAS usage, to ensure files are available whenever I want them.  I wanted to know what else I can run on the box at the same time since it is going to be on and consuming electricity anyway.

From highest and most user-friendly level to the lowest, they are:

1) FreeNAS Plug-in: This is how I got started with Plex media server, as it is one of the few plug-ins on the default list. Some flaws with this system were visible immediately. The version of Plex on the default plug-in library is several versions out of date, and there is no user-friendly update mechanism. The user has to go into the FreeBSD jail and update manually. Similarly, in order to access the media files hosted on the same FreeNAS box, the user has to know about manually mapping storage into FreeBSD jails.

It feels like the FreeNAS plug-in ecosystem never matured as much as the creators had hoped. A sentiment confirmed by this page. It explained the reasoning behind the push in FreeNAS 10 (Corral) to move to a system based on Docker containers. Unfortunately, when FreeNAS 10 was abandoned, that push was also put on hold.

Summary: It looks like FreeNAS plug-ins are a dead-end for a deprecated architecture.

2) FreeBSD Jail: Since a FreeNAS plug-in user basically had to know about running a FreeBSD Jail anyway, they might as well learn to work at this more hands-on level rather than depending on the FreeNAS plug-in architecture to sugar-coat it. There are a lot more steps involved, but for popular things, somebody would have posted the list of steps. For example, here's how to install Plex in a jail. (UPDATE: I've learned Plex media server is part of the standard package system and therefore even easier to install: Create a jail, open shell to the jail, type 'pkg install plexmediaserver', done.)

Upside: FreeBSD jails' isolation protects FreeNAS from some security exploits. The resources consumed by a jail is managed by the same system that manages the rest of FreeNAS and automatically gains all the benefits thereof. Storage in a jail can be mapped to a FreeNAS storage volume to allow (optionally read-only) access.

Downside: FreeBSD jails offers no protection against the nastier kernel-level security exploits.

Summary: FreeBSD Jail makes sense for running relatively trustworthy code that integrates with the volumes on FreeNAS. Plex media server is a good example.

3) Virtual Machine: New in FreeNAS 11 is a feature to create and run virtual machines alongside FreeNAS using the FreeBSD bhyve hypervisor. As of FreeNAS-11-0-U1, this new feature is quite immature. For example, trying to stop a VM in the FreeNAS UI seems to have no effect. I have to go into the administrative shell and use the "bhyvectl' command-line utility to stop the VM. As another example, the virtual UEFI boot sequence doesn't act as some operating systems expect, which can result in the user getting dumped into the UEFI shell. (Something normal users should never see!)

UEFI Shell

Google pointed me to this page which will help with most Linux distributions that encounter this problem. Thanks to this tip, I got my Ubuntu test server up and running on a FreeNAS VM.

Upside: Full virtual machine isolation will protect against most security exploits.

Downside: Full virtual machine isolation consumes more system resources. Most significantly, the storage is not shared: Space dedicated to a VM is not available to the rest of FreeNAS. And there is no storage mapping so a VM could only access FreeNAS shares over the network interface as if it is physically a different machine.

Summary: Virtual machines make sense for things that do not interact with the rest of FreeNAS, and a good alternative to setting up another physical machine.