Understanding bind mount point permissions

[YamiGhor]

Hello and first of all apologies because I couldn't understand all the threads and the documentation in https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

I expose my case. I have openmediavault VM with smb shared directory. I can access it from my personal computer and write and create files.
I have a transmission LXC with a MP to the SMB storage mapped on the host. And I can access it but don't have write permissions.

.conf file

arch: amd64
cores: 2
features: keyctl=1,nesting=1
hostname: transmission
memory: 2048
mp0: /mnt/pve/MEDIA,mp=/media/Media
net0: name=eth0,bridge=vmbr0,gw=xxx.xxx.xxx.xxx,hwaddr=xx:xx:xx:xx:xx:xx,ip=xxx.xxx.xxx.xxx/24,type=veth
onboot: 1
ostype: debian
rootfs: DATA:106/vm-106-disk-0.raw,size=8G
swap: 512
tags: home;media
unprivileged: 1

I know I have to grant permissions inside the config but I don't understand how.
The uid:

root@transmission:/media/Media# id
uid=0(root) gid=0(root) groups=0(root)

How can I follow from here?
Thanks in advance.

 

[YamiGhor]

Tried to follow the documentation adding these lines to the config

lxc.mp0: u 100000 100000 1
lxc.mp0: g 100000 100000 1

but still permission denied

 

[dakralex]

Welcome to the Proxmox forum, YamiGhor!

lxc.mp0: u 100000 100000 1
lxc.mp0: g 100000 100000 1

First, these should probably be lxc.idmap and second these id mappings say, that the container's uid and gid 100000 should be mapped to the host's uid and gid 100000, which is probably not what you want. These high-numbered ids are usually reserved exactly for the purpose of containers.

The example in the linked wiki article might seem a little daunting at first, but to break it in little steps:

• The container has 65536 ids available for users and groups, which is specified in /etc/subuid and /etc/subgid with root:100000:65536
• That means that inside a container, the user id 0 (which is the root user) is the user id 100000 on the host.
• Normal user accounts are typically allocated from user id 1000 onwards, the same applies for group ids. Normally each user has its own group.

So back to the example, the first two lines do say, that the first 1005 user/group ids for should stay mapped to the container's user/group id, so the container's user/group id 0 to 1004 are still mapped to 100000 to 101004 as before.

lxc.idmap = u 0 100000 1005
lxc.idmap = g 0 100000 1005

Then the next two lines, specifically allow that the container's user/group id 1005 is mapped to the host's 1005, which was previously mapped to 101005. This is the most important part!

lxc.idmap = u 1005 1005 1
lxc.idmap = g 1005 1005 1

And then the last two lines specify that the rest of the user/group ids should also still be mapped to what they were previously, i.e. the container's user/group id 1006 to 65536 should be still mapped to the host's 101006 to 165536.

lxc.idmap = u 1006 101006 64530
lxc.idmap = g 1006 101006 64530

Keep in mind that the latter part of actually allowing the host's root user (who starts the container) and its group to actually do this id mapping from 1005 to 1005 in both /etc/subuid and /etc/subgid:

root:1005:1

I hope this makes the article's instructions and description a little more clearer with a little more context.

 

[YamiGhor]

Welcome to the Proxmox forum, YamiGhor!



First, these should probably be lxc.idmap and second these id mappings say, that the container's uid and gid 100000 should be mapped to the host's uid and gid 100000, which is probably not what you want. These high-numbered ids are usually reserved exactly for the purpose of containers.

The example in the linked wiki article might seem a little daunting at first, but to break it in little steps:

• The container has 65536 ids available for users and groups, which is specified in /etc/subuid and /etc/subgid with root:100000:65536
• That means that inside a container, the user id 0 (which is the root user) is the user id 100000 on the host.
• Normal user accounts are typically allocated from user id 1000 onwards, the same applies for group ids. Normally each user has its own group.

So back to the example, the first two lines do say, that the first 1005 user/group ids for should stay mapped to the container's user/group id, so the container's user/group id 0 to 1004 are still mapped to 100000 to 101004 as before.

lxc.idmap = u 0 100000 1005
lxc.idmap = g 0 100000 1005

Then the next two lines, specifically allow that the container's user/group id 1005 is mapped to the host's 1005, which was previously mapped to 101005. This is the most important part!

lxc.idmap = u 1005 1005 1
lxc.idmap = g 1005 1005 1

And then the last two lines specify that the rest of the user/group ids should also still be mapped to what they were previously, i.e. the container's user/group id 1006 to 65536 should be still mapped to the host's 101006 to 165536.

lxc.idmap = u 1006 101006 64530
lxc.idmap = g 1006 101006 64530

Keep in mind that the latter part of actually allowing the host's root user (who starts the container) and its group to actually do this id mapping from 1005 to 1005 in both /etc/subuid and /etc/subgid:

root:1005:1

I hope this makes the article's instructions and description a little more clearer with a little more context.

Thank you very much for your explanation.
I feel like I understand but obiously I don't because I can't replicate it to my case, sorry.

I'll keep trying things.