<sabnzbd_root> =
/mnt/volume0/jails/sabnzbd_1
<couchpotato_root> =
/mnt/volume0/jails/couchpotato_1
<sonarr_root> =
/mnt/volume0/jails/sonarr_1
<sabnzbd_root>/etc/groups - Groups visible to sabNZBd jail (not viewable by FreeNAS GUI)
<sabnzbd_root>/etc/passwd - Users visible to sabNZBd jail (not viewable by FreeNAS GUI)
The <sabnzbd_root> folder is the base folder for the sabnzbd jail. A 'jail' is also referred to as a 'sandbox' in some contexts. Basically, it is a separate system-within-a-system where anything running in the jail has no idea about anything outside the jail and
typically can only access files within its own system. From the point of view of sabnzbd, it will see the folder
/media and think it is at the root location. NOTE: Whenever programming paths inside Sabnzbd, Couchpotato, Sonarr, it will always be relative to their respective jail root folders. However, in reality this folder is actually mapped to
<sabnzbd_root>/media (or
/mnt/volume0/jails/sabnzbd_1/media in its expanded form). This obviously creates a problem, since we want the output of sabnzbd to be accessed by other programs running in other jails (such as Couchpotato, SickBeard, Sonarr, etc). The solution is to create a link between the Sabnzbd jail and the main FreeBSD system, which I did through the FreeNAS GUI (->jails->sabnzbd_1->add storage). I created a link between
<sabnzbd_root>/media and
/mnt/volume0/media, which acts as a tunnel outside of the sandbox/jail for sabnzbd's output, so others can access the files. Similarly, in the CouchPotato and Sonarr jails, I created a tunnel from the
<couchpotato_root>/media and
<sonarr_root>/media folders to
/mnt/volume0/media, so they can use the sabnzbd downloads as inputs to their programs. Programs running outside the jail and inside the main FreeBSD system (ie. FreeNAS & GUI) can see all files within all jails.
There are a few options when trying to access files within the sabnzbd jail.
- Use an SSH terminal (Putty or Bitvise) into the FreeBSD system or open a web-based terminal/console from the left hand menu on the FreeNAS GUI. Using a text editor such as (vi or nano) to edit the files /mnt/volume0/jails/sabnzbd_1/etc/groups and /mnt/volume0/jails/sabnzbd_1/etc/passwd
- From the FreeNAS GUI there is a button at the bottom of the 'jails' tab for each jail. Open a web-based terminal/console for the sabnzbd jail and you can use a text editor (vi or nano) to edit the files /etc/groups and /etc/passwd. Remember that from the jail's perspective all files are relative to it's root (/mnt/volume0/jails/sabnzbd_1 in this case)
From the jail's perspective it is using the UID and GID for the user:group defined within it's version of
<sabnzbd_root>/etc/groups and
<sabnzbd_root>/etc/passwd, when creating new files. However, once those files exist outside the jail/sandbox and into the main FreeBSD system, then it is the actual
/etc/groups defined GID and
/etc/passwd defined UID that must be set properly to match the settings of the (in my setup)
/mnt/volume0/media dataset. To ensure the permissions are set properly from the output of Sabnzbd, I have enabled the file ownership modifications. The output of Sabnzbd (copied to
/mnt/volume0/media/Downloads/complete) will have ownership changed (a.k.a. unix command: chown) to group 'media' and user 'media' with file permissions '660' and folder permissions '770'. This is necessary since the Sabnzbd process is run as group 'wheel' and user 'root' within it's own jail, so I want created/moved files into the final
/mnt/volume0/media dataset to belong to group 'media' and user 'media' otherwise SAMBA/NFS services could not host the files properly. To reiterate, when I told Sabnzbd to change ownership to group 'media' and user 'media', all of those are ALWAYS in reference to what it thinks those GID and UID are, as defined within
<sabnzbd_root>/etc/groups and
<sabnzbd_root>/etc/passwd.