[HOW TO] FN11.1 Docker VM, Rancher, Plex, Tautulli, Ombi, Deluge w/OpenVPN & PIA, Sickrage, & More

[NetSoerfer]

@dublea On fact you do not address is that in the current FreeNAS implementation the base rancheros is not user upgradable. There have been numerous releases since v1.1.3 and v1.3.0 is due soon.

https://github.com/rancher/os/releases

Does this mean that once installed, I will be stuck with RancherOS v1.1.3 forever, or will RancherOS be updated along with updates to FreeNAS?

 

[KrisBee]

Hard to say. It only went from an earlier version to v.1.1.3 because an issue was raised at https://redmine.ixsystems.com/ some time ago. I suspect unless users of rancheros raise this issue again, nothing will happen. It's just one reason why I wouldn't use rancheros at the moment.

 

[dublea]

Something I noticed while trying to fix issues with my Rancher server becoming unreachable:

Turns out Rancher tries to use a subnet that's already in use in my home network. If you use any subnets in the 10.42.0.0/16 (10.42.x.x) range, they will collide with Rancher's default managed network (see Rancher FAQ for more information):


To prevent Rancher from using a subnet that will collide with any existing subnets you may have in the 10.42.x.x range, set a different managed network in the Cattle Environment Template (see attached screenshots if you can't find where to do the below steps):

• Go to Manage Environments
  
• Edit the Cattle Environment Template
• Scroll to the Networking services and click Edit Config for the Rancher IPsec service
• In the Configuration Options section, change the Subnet variable to an unused subnet
  (note that this is a /16 subnet - so if you set 10.32.0.0/16, Rancher will use up the entire IP range from 10.32.0.0 to 10.32.255.255!)
• Scroll down and click Configure to return to the Environment Template, then don't forget to scroll all the way down to actually Save the Environment Template's changed configuration!

10.42.0.0/16 (10.42.x.x) are not your typical subnets. Thanks for pointing this out for the ones it may affect though!

@dublea One fact you do not address is that in the current FreeNAS implementation the base rancheros is not user upgradable. There have been numerous releases since v1.1.3 and v1.3.0 is due soon.

https://github.com/rancher/os/releases

I was not aware they did not include the latest version, but considering how it's provided, it's logical to assume to be the case. Initially, I worked with the built in RancherOS but then migrated away from it to Ubuntu Server. Prior to going with Ubuntu, I did consider using the latest version and manually installing it in the same way I did Ubuntu but did not. I can add that once I verify the How-To. I migrated to Ubuntu as I could install and configure apps directly on the host OS for the sake of managing and maintaining the VM in my environment.

 

[dublea]

Hard to say. It only went from an earlier version to v.1.1.3 because an issue was raised at https://redmine.ixsystems.com/ some time ago. I suspect unless users of rancheros raise this issue again, nothing will happen. It's just one reason why I wouldn't use rancheros at the moment.

Yet another reason as to why I migrated to Ubuntu Server... now almost any linux distro could work, I just chose Ubuntu due to it's popularity. I do plan on adding other distro so users have choice IF they chose to use Docker|Rancher instead of Jails.

 

[KrisBee]

@dublea Looking at the Ubuntu-Server part of your comprehensive how-to, a better post-install fix for UEFI booting is to execute this command once as root post Ubuntu install:

grub-install --efi-directory=/boot/efi --boot-directory=/boot --removable

Rancher themselves seem to go with Ubuntu and using this as a base would allow someone to migrate to Rancher 2 if and when it becomes available. The downside is an Ubuntu server install can drag in a lot of packages and services you might never need and there's even more stuff coming in 18.04 LTS.

 

[NetSoerfer]

Another thing I noticed: If I use hostnames to mount the cifs shares, mounting will fail because I haven't added a DNS server.

To do this, RancherOS will accept the following:
sudo ros config set rancher.config.dns.nameservers [10.0.0.1]

 

[dublea]

@KrisBee Thanks for the tip for the grub fix! All I could find were others doing the same as I did and was unaware of a better way. I'll add that to be apart of the next update.

Also, good to know about Rancher and Ubuntu. IMO, while it may come with packages and services you might never need, one can always disable and configure the defaults to their own specifications and needs. I do this with any OS I utilize, Windows, Linux, macOS, etc.

 

[dublea]

Another thing I noticed: If I use hostnames to mount the cifs shares, mounting will fail because I haven't added a DNS server.

To do this, RancherOS will accept the following:
sudo ros config set rancher.config.dns.nameservers [10.0.0.1]

I've always used IP vs hostnames when mounting shares as it can be a point of failure IF something occurs with your DNS(s). But, I will add the DNS command to the static IP section on my next update.

 

[NetSoerfer]

I've always used IP vs hostnames when mounting shares as it can be a point of failure IF something occurs with your DNS(s). But, I will add the DNS command to the static IP section on my next update.

Well, I'm stuck getting the cifs shares mounted anyway. My configuration reads as follows:

Code:

[rancher@rancher ~]$ sudo ros config export
EXTRA_CMDLINE: /init
mounts:
- - //hostname.suffix/backups
  - /media/backups
  - cifs
  - username=backupuser,password=pass1234,iocharset=utf8,_netdev
rancher:
  environment:
	EXTRA_CMDLINE: /init
  network:
	dns:
	  nameservers:
	  - 10.42.1.1
	interfaces:
	  eth0:
		address: 10.42.1.3/24
		dhcp: false
		gateway: 10.42.1.1
		mtu: 1500
  password: 1234pass
  resize_device: /dev/sda
  state:
	dev: LABEL=RANCHER_STATE
	wait: true
ssh_authorized_keys: []

Still, that share isn't mounted on reboot.

Oddly though, the following command does mount the share just fine:

Code:

[rancher@rancher ~]$ sudo mount -t cifs -o username=backupuser,password=pass1234,iocharset=utf8,_netdev //hostname.suffix/backups /media/backups

What am I doing wrong, any ideas?

(edited the above from QUOTE to CODE tags to retain formatting.)

 

[dublea]

mounts:
- - //hostname.suffix/backups
- /media/backups
- cifs
- username=backupuser,password=pass1234,iocharset=utf8,_netdev

Cannot tell if it's just the way it is posted, but you have to have spaces on the last three lines:

Code:

mounts:
- - //hostname.suffix/backups
  - /media/backups
  - cifs
  - username=backupuser,password=pass1234,iocharset=utf8,_netdev

If it's just the way it is posted, I would first check into your system logs.

 

[Tim Smit]

Hi, I'm having trouble with the most recent guide: installing Ubuntu + Docker + Rancher. Everything goes smoothly until I try to add my Docker as a host in Rancher. Some pre info

• My NAS is tied to IP 192.168.2.22
• Ubuntu VM is tied to IP 192.168.2.34

I can access the Rancher web GUI, but once I have pasted the agent activation string Ubuntu cant connect. Any ideas?

Code:

ERROR: http://192.168.2.34:8080/v1 is not accessible (The requested URL returned error: 404 not found)

 

[dublea]

@Tim Smit From what I've found, it may be an issue with iptables.

 

[NetSoerfer]

edit: after several days spent trying to get to the bottom of these issues, simply rebooting the docker host after installing ecoDMS seems to have done the trick.

OK, so I've switched from RancherOS to Ubuntu Server following KrisBee's remark about the uncertainty of Rancher upgrades with the RancherOS image. But I'm having troubles with the CIFS shares now.

I've created a unix-type dataset 'ecoDMS' for a container and shared it via CIFS. I have successfully mounted it in the Docker Ubuntu VM.

When I try to run the 'ecoDMS' container for the first time, it tries to create four directories inside the 'ecoDMS' share, for the four directories I mount inside the container.

docker run --restart=always -it -d -p 17001:17001 -p 17004:8080 --name "ecodms" -v /media/ecoDMS/data:/srv/data -v /media/ecoDMS/scaninput:/srv/scaninput -v /media/ecoDMS/backup:/srv/backup -v /media/ecoDMS/restore:/srv/restore -t ecodms/allinone-16.09

I get a permission denied error though:

docker: Error response from daemon: error while creating mount source path '/media/ecoDMS/scaninput': chown /media/ecoDMS/scaninput: permission denied.

The directory ('scaninput' in this case) is created though. If I run it again, I will get the error for the next directory, not for the 'scaninput' directory. Looks like it only tries (or fails) to chown newly created directories.
If I create the directories upfront, the subsequent installation of ecoDMS inside the container will show very similar errors for the directories and files created during the installation.

log.smbd on FreeNAS doesn't show any errors for these operations, suggesting that the problem lies elsewhere. I'm guessing unix filesystem permissions, but how do I find out what the correct permissions would be?

 

[J. Greg Williams]

Hard to say. It only went from an earlier version to v.1.1.3 because an issue was raised at https://redmine.ixsystems.com/ some time ago. I suspect unless users of rancheros raise this issue again, nothing will happen. It's just one reason why I wouldn't use rancheros at the moment.

How do I go about formally raising this issue again? It's pretty frustrating to run the ros os upgrade only to find that it's not actually switching to the latest version on reboot. Rancher 2.0 seems to solve many of my problems and wouldn't install unless I upgraded.

 

[dublea]

How do I go about formally raising this issue again? It's pretty frustrating to run the ros os upgrade only to find that it's not actually switching to the latest version on reboot. Rancher 2.0 seems to solve many of my problems and wouldn't install unless I upgraded.

You can raise a ticket with them here. When I go to update the guide (had a very very busy past couple months...) I'm going to replace the RancherOS section with using an ISO from them. To be honest, I recommend Ubuntu Server still though over RancherOS.

 

[J. Greg Williams]

You can raise a ticket with them here. When I go to update the guide (had a very very busy past couple months...) I'm going to replace the RancherOS section with using an ISO from them. To be honest, I recommend Ubuntu Server still though over RancherOS.

Thanks. I like the idea of using rancheros as it's very lightweight, leaving more resources for the actual containers I want to be running. But I suspect I'll need to run a full vm in order to actually get anything to work. Thanks for the link.

 

[KrisBee]

Thanks. I like the idea of using rancheros as it's very lightweight, leaving more resources for the actual containers I want to be running. But I suspect I'll need to run a full vm in order to actually get anything to work. Thanks for the link.

rancheros is not encumbered by systemd, but is really that lightweight? I don't have the figures to hand, but I seem to remember a minimum debian netinstall plus latest docker and compose had a lower memory footprint.

I'm not surprised @dublea suggests using an Ubuntu VM as a docker base. But I was intrigued to read @dublea 's comment about

I'm going to replace the RancherOS section with using an ISO from them.

Has the latest rancheros iso suddenly become EFI aware? Or is there a way to boot a syslinux based rancheros iso with bhyve's grub-loader after all?

 

[bigverm23]

@dublea going through this guide and have a few simple questions hopefully. I am going the Ubuntu/Docker-Rancher route and have come to the Mounting CIFS section:

At the end of the file, we need to mount our shares by adding the following
//{FreeNAS}/Backup /media/Backup cifs username={Username},password={Password},iocharset=utf8,sec=ntlm 0 0
//{FreeNAS}/Downloads /media/Downloads cifs username={Username},password={Password},iocharset=utf8,sec=ntlm 0 0
//{FreeNAS}/Media /media/Media cifs username={Username},password={Password},iocharset=utf8,sec=ntlm 0 0
//{FreeNAS}/Nextcloud /media/nextcloud cifs username={Username},password={Password},iocharset=utf8,sec=ntlm 0 0

is the above the recommended shares setup or are you just providing a model to follow?
my current setup is
volume = /media
datasets = /Storage, /Downloads, /Movies, /TorrentFiles

Would I mount each of the above datasets as a separate share (I'll be using NFS), and then when it comes to adding the Plex Media Stack, would I add these 4 volumes instead of the /media/Media?

 

[Spencer Skinner]

Hi

Ive had a few issues with setting up the plex container, ive followed the guide as follows
Ports set to 32400, TZ set to GB, PLEX_CLAIM set to nothing, Networking on Host mode, and the volumes as follows -
/media/VMRoot/VMDocker/Docker_Configs/Plex-A1/config/:/config
/media/VMRoot/VMDocker/Docker_Configs/Plex-A1/transcode/:/transcode

Ive left the data volume un-mapped as I want to get it all working first

I only get this issue when I add the volumes, when i leave them all blank it works perfectly. Here is what I get in the logs when I do add the volumes -

Code:

28/06/2018 22:32:26[services.d] done.
28/06/2018 22:32:26Starting Plex Media Server.
28/06/2018 22:32:26terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
28/06/2018 22:32:26  what():  boost::filesystem::create_directory: Permission denied: "/config/Library/Application Support/Plex Media Server/Logs"
28/06/2018 22:32:26****** PLEX MEDIA SERVER CRASHED, CRASH REPORT WRITTEN: /config/Library/Application Support/Plex Media Server/Crash Reports/1.13.2.5154-fd05be322/PLEX MEDIA SERVER/215000c1-ba32-c6d1-69812f4e-4ef86ccf.dmp
28/06/2018 22:32:26Aborted

The volumes are all set with the permissions 777 so I'm not 100% sure why this is happening, Ive also tried this same setup and added PUID and PGID to the parameters and used the IDs of the user and group which own the config and transcode directory. Any ideas what Im doing wrong here

Thanks!

 

[Spencer Skinner]

Hi

I've had a few issues with setting up the plex container, I've followed the guide as follows
Ports set to 32400, TZ set to GB, PLEX_CLAIM set to nothing, Networking on Host mode, and the volumes as follows -
/media/VMRoot/VMDocker/Docker_Configs/Plex-A1/config/:/config
/media/VMRoot/VMDocker/Docker_Configs/Plex-A1/transcode/:/transcode

I've left the data volume un-mapped as I want to get it all working first

I only get this issue when I add the volumes, when i leave them all blank it works perfectly. Here is what I get in the logs when I do add the volumes -

Code:

28/06/2018 22:32:26[services.d] done.
28/06/2018 22:32:26Starting Plex Media Server.
28/06/2018 22:32:26terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
28/06/2018 22:32:26  what():  boost::filesystem::create_directory: Permission denied: "/config/Library/Application Support/Plex Media Server/Logs"
28/06/2018 22:32:26****** PLEX MEDIA SERVER CRASHED, CRASH REPORT WRITTEN: /config/Library/Application Support/Plex Media Server/Crash Reports/1.13.2.5154-fd05be322/PLEX MEDIA SERVER/215000c1-ba32-c6d1-69812f4e-4ef86ccf.dmp
28/06/2018 22:32:26Aborted

The volumes are all set with the permissions 777 so I'm not 100% sure why this is happening, I've also tried this same setup and added PUID and PGID to the parameters and used the IDs of the user and group which own the config and transcode directory. Any ideas what Im doing wrong here

Thanks!

Solved the issue, turns out I needed to change PUID and PGID to PLEX_UID and PLEX_GID, works a dream now