SOLVED 11.2-U2.1 Docker Woes

[sretalla]

Also, what happens if you put a file in those empty locations? Does it survive a reboot and can you see it from the FreeNAS side?

 

[sretalla]

What permissions should I have on my datasets / folders in FreeNAS and also in nfs shares?

I think we mentioned the UID story in an earlier section of the thread, but ultimately, you want the container user and group IDs as the user/group with full rights on the filesystem (with a matching user/group on FreeNAS with matching IDs). On NFS, it’s simplest to have root:wheel.

 

[SavageAUS]

I think we mentioned the UID story in an earlier section of the thread, but ultimately, you want the container user and group IDs as the user/group with full rights on the filesystem (with a matching user/group on FreeNAS with matching IDs). On NFS, it’s simplest to have root:wheel.

So when I setup my nfs shares I should have mapallgroup wheel and mapalluser to root?
And which ever user I have created for access, use that puid and pgid? So if user has ids of 1001 I set those in environmental values as displayed?
I still can’t get anything to work/mount properly and it’s driving me insane as my jails aren’t working correctly either.

 

[sretalla]

The best way to start working through it is to go to the container in Rancher and from the 3 dots on the right, go to Execute Shell.

This then allows you to navigate to the directory you think isn't doing what you expect and do things like put a file there and see if it shows up on FreeNAS. Also to ls -l and see the permissions according to the container.

 

[SavageAUS]

The best way to start working through it is to go to the container in Rancher and from the 3 dots on the right, go to Execute Shell.

This then allows you to navigate to the directory you think isn't doing what you expect and do things like put a file there and see if it shows up on FreeNAS. Also to ls -l and see the permissions according to the container.

So I did as you suggested finally and added a test.txt into the config folder within sonarr and it survived a reboot with permissions of root:root.

 

[sretalla]

So I did as you suggested finally and added a test.txt into the config folder within sonarr and it survived a reboot with permissions of root:root.

And can you find that file in the FreeNAS filesystem where the rancher-nfs volume is pointing?

 

[SavageAUS]

And can you find that file in the FreeNAS filesystem where the rancher-nfs volume is pointing?

Unfortunately I cannot find it in the dataset that was pointed at it.

 

[sretalla]

Unfortunately I cannot find it in the dataset that was pointed at it.

OK, so this means it's not really doing the redirection according to the volume setup.

What does the volume setup look like for that container?

What is the setup for that volume in the storage section?

 

[SavageAUS]

For the rancher-nfs volume creation I do:
Name : sonarrconfig
host - 192.168.1.2 <- FreeNAS
export - /mnt/JailsSSD/Sonarr/ <- config for sonarr
onRemove - retain

When creating the container I setup as follows:
sonarrconfig:/config:rw
rancher-nfs

Obviously with more volumes but all setup the same pointing to different datasets.

 

[sretalla]

So all that looks right... something really doesn't smell like it should here...

Can you go to the stack in Rancher for Sonarr and export the config and share it here?

 

[SavageAUS]

When I go into stacks there is none for sonarr. I haven’t created a stack. I just create containers. Could that be the problem?

 

[SavageAUS]

Should I also create a network?

 

[sretalla]

You don't "need" to have a stack... it's useful for some things like moving between hosts/load balancing and for upgrading containers (which effectively means editing the container config after creation for any reason... but also to upgrade the container image as would be implied by the "upgrade").

I guess it means you delete and re-create the containers as you need to change anything (multiplying the chances for error) and can't easily get to the docker compose statement that's behind the container (which is really easy in a stack).

Maybe everything ends up in the default stack, so possibly you do have at least one...? Nope, just tested it, you land in the "standalone containers" area on the host, so no stack.

I recommend having a stack. (even one for each "application", since that makes the config nice and clean for each rather than one which has all your containers in it).

If you just add a stack and then add a Service to that stack, you'll be in a familiar place.


Networks aren't necessary, that's largely handled automatically by Rancher and Docker unless you have something really special to do other than publishing ports to the outside world.

 

[SavageAUS]

You don't "need" to have a stack... it's useful for some things like moving between hosts/load balancing and for upgrading containers (which effectively means editing the container config after creation for any reason... but also to upgrade the container image as would be implied by the "upgrade").

I guess it means you delete and re-create the containers as you need to change anything (multiplying the chances for error) and can't easily get to the docker compose statement that's behind the container (which is really easy in a stack).

Maybe everything ends up in the default stack, so possibly you do have at least one...? Nope, just tested it, you land in the "standalone containers" area on the host, so no stack.

I recommend having a stack. (even one for each "application", since that makes the config nice and clean for each rather than one which has all your containers in it).

If you just add a stack and then add a Service to that stack, you'll be in a familiar place.


Networks aren't necessary, that's largely handled automatically by Rancher and Docker unless you have something really special to do other than publishing ports to the outside world.

Adding a stack then creating a service results in a non accessible container.

 

[sretalla]

Adding a stack then creating a service results in a non accessible container.

It will produce a container with an identical result to creating a container yourself, so that can't be it... we need to look at the settings. Can you export the config of the stack and share it please?