Greetings folks,
I've been trying to get a Samba share set up through an unprivileged Alpine LXC container. I have a ZFS storage pool that I would like to share with this (and other) containers. Thing is I want to do this with a recursive bindmount so that I can have other containers use the same data (say mounting it read-only for a media server)*. Unfortunately I don't think creating a storage provider and using that will work for this because I want to access the contents of the directory rather than mounting a block of storage inside that directory, so from what I tested adding a "zfs" storage provider from the GUI is out. It does look like I can add a mountpoint though:
https://pve.proxmox.com/wiki/Unprivileged_LXC_containers
I also have many zfs datasets and would like to keep adding more, and unfortunately sharing the parent bind mount doesn't get all of its children... go figure. Having to edit the configuration of the storage container all the time to add more binds is out of the question (especially is the cap is 32 like I've heard)... I'd likely pursue a different solution to my problem if that was my only answer.
This introduces two problems, because I have many datasets I would like to share which are children of a common dataset, and it doesn't look like rbind is implemented yet for mp. I also need to set permissions correctly so that I can access the contents in the unprivileged container correctly. I haven't touched the later yet, but I have attempted the former and am a bit baffled by what I'm seeing here.
For the sake of the following examples and to be painfully clear, `mypool/share` is the dataset I would like to share that contains two child datasets, `mypool/share/foo` and `mypool/share/bar`. The directory I want these to appear on in the Alpine container is `/samba`, so the contents of `/samba/bar` should be equivalent to `mypool/share/bar`. Additionally, all datasets are mounted on root with a similar structure, so dataset `mypool/share/foo` is mounted at `/mypool/share/foo` on the host.
For instance, I set up the container with it's root storage in a separate pool and do a simple bind mount with pct like so:
`pct set 100 -mp0 /mypool/share,mp=/samba`
This performs as I expected, I can see `/samba` in the container, and even the directories `foo` and `bar`, but neither has any contents.
So, I add another line to the end of `/etc/pve/lxc/100.conf` (100 being the ID of the alpine container), and add
`lxc.mount.entry: /mypool/share /samba/ none rbind,create=dir,optional 0 0`
I've seen this on the forums before as a valid way to address this problem:
https://forum.proxmox.com/threads/b...iles-in-nested-zfs-datasets.47454/post-382266
The issue though is I'm having the exact same problem another user is having as of last September:
https://forum.proxmox.com/threads/permission-issues-on-rbind-mounts-to-lxc.114551/
The issue is that the rbind just outright doesn't work. Where my expectation is that the rbind would show me all the contents of `samba` so that I could look into `/samba/foo` and `/samba/bar` and see their files, I don't see anything! To make matter worse, I tried to start up a different privileged container that follows the same process, but instead of running the `pct` command I only add in the `lxc.mount.entry` configuration - that leads the container to not start properly at all! I don't think this should be possible given that the `optional` flag specifically instructs the container to not fail if the mount does not work, and `create=dir` should make the directory structure anyways.
To round this out, it even looks like there is a patch available to add `rbind` to the mp-syntax, here, which would be the ideal solution to this problem:
https://bugzilla.proxmox.com/show_bug.cgi?id=2762
But I've never seen the "patch available" status and it isn't explained in the field explanation blurb:
https://bugzilla.proxmox.com/page.cgi?id=fields.html#bug_status
Supposedly this patch has been available since mid 2020, but I have no idea how to access it or if I should expect that I can use it in a non-enterprise application, but adding complexity by applying a patch ontop of my proxmox installation every time I update the OS? Yeah no thanks, that's insane to expect that over merging it into mainline.
tl;dr and summary:
I've given a pretty good shot at getting a recursive bind mount to a container from a ZFS dataset mounted to the host to work, but I'm getting a very opaque and confusing result and I need some help.
Thanks folks!
* I want to acknowledge the possibility of write collisions if you have multiple containers accessing the same directory, though I'd be curious to hear if a separate NFS and Samba container would be smart enough to avoid colliding with each other. If so I'd just run the services in the same container and call it a day, since I'm fairly sure modern filesystems handle that pretty well, but otherwise running them in separate containers would be helpful if it's possible.
I've been trying to get a Samba share set up through an unprivileged Alpine LXC container. I have a ZFS storage pool that I would like to share with this (and other) containers. Thing is I want to do this with a recursive bindmount so that I can have other containers use the same data (say mounting it read-only for a media server)*. Unfortunately I don't think creating a storage provider and using that will work for this because I want to access the contents of the directory rather than mounting a block of storage inside that directory, so from what I tested adding a "zfs" storage provider from the GUI is out. It does look like I can add a mountpoint though:
https://pve.proxmox.com/wiki/Unprivileged_LXC_containers
I also have many zfs datasets and would like to keep adding more, and unfortunately sharing the parent bind mount doesn't get all of its children... go figure. Having to edit the configuration of the storage container all the time to add more binds is out of the question (especially is the cap is 32 like I've heard)... I'd likely pursue a different solution to my problem if that was my only answer.
This introduces two problems, because I have many datasets I would like to share which are children of a common dataset, and it doesn't look like rbind is implemented yet for mp. I also need to set permissions correctly so that I can access the contents in the unprivileged container correctly. I haven't touched the later yet, but I have attempted the former and am a bit baffled by what I'm seeing here.
For the sake of the following examples and to be painfully clear, `mypool/share` is the dataset I would like to share that contains two child datasets, `mypool/share/foo` and `mypool/share/bar`. The directory I want these to appear on in the Alpine container is `/samba`, so the contents of `/samba/bar` should be equivalent to `mypool/share/bar`. Additionally, all datasets are mounted on root with a similar structure, so dataset `mypool/share/foo` is mounted at `/mypool/share/foo` on the host.
For instance, I set up the container with it's root storage in a separate pool and do a simple bind mount with pct like so:
`pct set 100 -mp0 /mypool/share,mp=/samba`
This performs as I expected, I can see `/samba` in the container, and even the directories `foo` and `bar`, but neither has any contents.
So, I add another line to the end of `/etc/pve/lxc/100.conf` (100 being the ID of the alpine container), and add
`lxc.mount.entry: /mypool/share /samba/ none rbind,create=dir,optional 0 0`
I've seen this on the forums before as a valid way to address this problem:
https://forum.proxmox.com/threads/b...iles-in-nested-zfs-datasets.47454/post-382266
The issue though is I'm having the exact same problem another user is having as of last September:
https://forum.proxmox.com/threads/permission-issues-on-rbind-mounts-to-lxc.114551/
The issue is that the rbind just outright doesn't work. Where my expectation is that the rbind would show me all the contents of `samba` so that I could look into `/samba/foo` and `/samba/bar` and see their files, I don't see anything! To make matter worse, I tried to start up a different privileged container that follows the same process, but instead of running the `pct` command I only add in the `lxc.mount.entry` configuration - that leads the container to not start properly at all! I don't think this should be possible given that the `optional` flag specifically instructs the container to not fail if the mount does not work, and `create=dir` should make the directory structure anyways.
To round this out, it even looks like there is a patch available to add `rbind` to the mp-syntax, here, which would be the ideal solution to this problem:
https://bugzilla.proxmox.com/show_bug.cgi?id=2762
But I've never seen the "patch available" status and it isn't explained in the field explanation blurb:
https://bugzilla.proxmox.com/page.cgi?id=fields.html#bug_status
Supposedly this patch has been available since mid 2020, but I have no idea how to access it or if I should expect that I can use it in a non-enterprise application, but adding complexity by applying a patch ontop of my proxmox installation every time I update the OS? Yeah no thanks, that's insane to expect that over merging it into mainline.
tl;dr and summary:
I've given a pretty good shot at getting a recursive bind mount to a container from a ZFS dataset mounted to the host to work, but I'm getting a very opaque and confusing result and I need some help.
Thanks folks!
* I want to acknowledge the possibility of write collisions if you have multiple containers accessing the same directory, though I'd be curious to hear if a separate NFS and Samba container would be smart enough to avoid colliding with each other. If so I'd just run the services in the same container and call it a day, since I'm fairly sure modern filesystems handle that pretty well, but otherwise running them in separate containers would be helpful if it's possible.
. For the sake of being thorough, here's my container config:
