Lxc with docker: apps do not see/cannot access proxmox bind mount share

[kiloxpor]

Hi,

I have docker installed in one of my lxc unpriviledged containers. This container has access to a nfs share in the promox host mounted under mnt/bindmounts/nfs. However, the apps I install in this lxc container/docker, like jellyfin for example, cannot access or do not seem to see this nfs share mounted under mnt/nfs.

I had a similar issue with a vm and docker, so I guess this has nothing to do with the fact this is an unpriviledged lxc container.

Could you help me understand why this is happening?

Thanks!

 

[Dunuin]

Did you change the user-remapping? With unprivileged LXCs by default no user (not even root) will be able to access a bind-mounted folder if that folder doesn't got 777 rights. Thats because your user with UID 0 to 65565 inside the LXC are the users with UID 100000 to 165565 on the host.

 

[kiloxpor]

Thanks a lot for the quick reply and the link. No, I did not touch the user mapping. What are 777 rights? I am still struggling a bit with this user mapping thing in unpriviledged containers, but I suspected this could be the problem.

There is something I do not quite understand yet: I can access/see (the content) of the bind mount/nfs share mounted under mnt/nfs inside this unpriviledged lxc container. But according to your message, it shouldn't be the possible because of the mapping issue? So normally, the docker container jellyfin should also see the share then?

I have jellyfin installed in another lxc unprivilegded container (directly in debian, not through docker) with access to the same nfs share bind mount, and jellyfin can access/see the content of the share in this case.

 

[Dunuin]

What are 777 rights?

Google for "chmod" to see how linux handles right management. "777" means basically everyone can do everything so there is no protection at all. And because NFS got no authentification by default that means everyone with access to your network can open or delete your stuff in that share.

There is something I do not quite understand yet: I can access/see (the content) of the bind mount/nfs share mounted under mnt/nfs inside this unpriviledged lxc container. But according to your message, it shouldn't be the possible because of the mapping issue?

It all depends on the rights of your NFS share. If your share for example has "775" rights everyone can see and execute files on that share but no one of your LXCs users will be able to write to it.

 

[kiloxpor]

Google for "chmod" to see how linux handles right management. "777" means basically everyone can do everything so there is no protection at all. And because NFS got no authentification by default that means everyone with access to your network can open or delete your stuff in that share.

Thanks a lot for the hint, I need to look into this.

In the example given in the link here , is "uid 1500" a possible restricted nfs share user id?

So is it recommended/best practice to have user restricted bind mount nfs shares? Can they still be shared among several lxc containers using the same mapped user id?

It all depends on the rights of your NFS share. If your share for example has "775" rights everyone can see and execute files on that share but no one of your LXCs users will be able to write to it.

I just checked and I can write to the nfs share within the lxc (possibly 777 then?). How do I see the nfs share rights? Should I modify these rights before doing the mapping to a specific user id in the lxc container? If I edit the nfs rules in my synology nas folder, I see "Squash: No mapping".

And how does this relate to my original problem? The jellyfin docker container that cannot access the bind mount share inside the lxc container... if it is 777, shouldn't the jellyfin docker container be able to access the bind mount share? Or this is maybe a docker specific problem?

 

[Dunuin]

So is it recommended/best practice to map each bind mount share in the host to a specific user id inside the container?

Jep and then exclude that user from remapping. For example the NFS share is owned by the user with the UID 1000, then you want that the user with UID 1000 inside your LXC is mapped to the user with the UID 1000 on the host (and not the user with the UID 101000). All other users should still be mapped to 100000-165535 for security. So 0-999 to 100000-100999, 1000 to 1000, 1001-65535 to 101001-165535.

Can this same bind mount share be shared among several lxc containers using the same user id?

Didn't tested it but should work.

How do I see the nfs share rights?

Run ls -la /path/where/you/mounted/that/nfs on your host.

Should I modify these rights before doing the mapping to a specific user id in the lxc container?

If you already got 777 rights you shouldn't need remapping. But security wise it isn't good if anyone may read/delete your stuff. Lets say you give a friend WIFI access. Now that fried got some free apps with malware installed on his phone and his phone is deleting all your media on that NFS share.
And because NFS doesn't got autentification it also would be better for security if you only allow access from specific IPs to that NFS share. There is no authentification, so even if that share is owned by user "bob" with UID 1000 and bobs account is password protected everyone can claim to be the user with the UID 1000 and NFS will accept them as bob without asking for bobs password. For actual NFS user authentification you would need to setup kerberos as a domain controller...complex topic...

In the example given in the link here , is "uid 1500" a possible restricted nfs share user id?

Thats UID 1005 is just an example. You could use any UID.

And how does this relate to my original problem? The jellyfin docker container that cannot access the bind mount share inside the lxc container... if it is 777, shouldn't the jellyfin docker container be able to access the bind mount share? Or this is maybe a docker specific problem?

Yes, if its 777 every LXC should be able to access it as long as that share isn't only allowing specific IPs to connect. I nthat case it must be another problem.

 

[Dunuin]

ls -la will show the rights in a more user friendly way. A "drwxrwxrwx 3 root wheel ..." will for example mean that it is a directory owned by the user "root" and the group "wheel" and it got 777 rights. The first 3 chars of "rwxrwxrwx" means the owner may read (r), write (w) and execute (x). Chars 4-6 mean the same but for the group that file/folder belongs to and chars 7-9 are rights for everyone else. So "rwxr-x---" (also known as "750" if you write it octal) would mean the owner may do everything, the group may only read and execute and everyone else has no access at all.

 

[kiloxpor]

ls -la will show the rights in a more user friendly way. A "drwxrwxrwx 3 root wheel ..." will for example mean that it is a directory owned by the user "root" and the group "wheel" and it got 777 rights. The first 3 chars of "rwxrwxrwx" means the owner may read (r), write (w) and execute (x). Chars 4-6 mean the same but for the group that file/folder belongs to and chars 7-9 are rights for everyone else. So "rwxr-x---" (also known as "750" if you write it octal) would mean the owner may do everything, the group may only read and execute and everyone else has no access at all.

Thanks, right, this is what I see:

drwxrwxrwx 1 root root 12134 Oct 26 00:22 .
drwxr-xr-x 3 root root 3 Oct 22 01:31 ..
-rw-rw-rw- 1 1026 users 520848492 Feb 7 2015 'example.mp4'
-rwxrwxrwx 1 1026 users 86255 Aug 10 2012 'example.srt'
etc...

The folder contains basically a bunch of video files (movies) in various formats plus subtitles files... Like you said, the folders are owned by root, but all the files are mostly "1026 users".

So this confirms that this nfs share is 777, right?

Just to underline however, like you mentioned in the previous message, that access to this nfs share is currently restricted to a single IP or IPs.

 

[Dunuin]

drwxrwxrwx 1 root root 12134 Oct 26 00:22 .
drwxr-xr-x 3 root root 3 Oct 22 01:31 ..
-rw-rw-rw- 1 1026 users 520848492 Feb 7 2015 'example.mp4'
-rwxrwxrwx 1 1026 users 86255 Aug 10 2012 'example.srt'
etc...

If they are all like that than it should be fine without remapping.