LXD (w/ NFS Shares)
I have a fairly cheap Synology system managing my spinning rust storage. Block storage over iSCSI didn't perform very well, so I ended up on NFS. NFS works well enough, but unfortunately the support to mount a remote export just isn't there yet. You'll need to mount the NFS share on the host, push the mount into the container as a disk object, and adjust permissions as needed. Here's how I've accomplished this.
NFS Mount
mkdir -p /mnt/share
vim /etc/fstab
ip.or.hostname:/volume1/share /mnt/share nfs4 defaults 0 0
mount /mnt/share
Prep Users & Permissions
I created system users and groups to handle the permissions of each share. I use the user to grant RW permissions, and the group to grant RO. I map the user and/or group to the user/group inside the container that needs access to the share.
addgroup --system --gid 300 mntShareRO
adduser --system --home /mnt/share --uid 300 --gid 300 mntShareRW
chown mntShareRW:mntShareRO /mnt/share
chmod 750 /mnt/share
chmod g+s /mnt/share
To allow a user to be remapped, you'll need to use /etc/subuid
for users & /etc/subgid
for groups
vim /etc/subuid
# /mnt/share: container-1
root:300:1
vim /etc/subgid
# /mnt/share: container-1 container-2
root:300:2
The format of the file is the root user, then the UID/GID to share, then how many shares are allowed. In the above example I've allowed 1 UID remap for RW access, and 2 GID remaps for RO access. To keep track of which container has access to what I like to add comments to ensure my numbers are accurate.
Configure the LXD Container
Use the following command to set the raw id mapping:
echo -en "uid 300 1000\ngid 300 1000" | lxc config set container-1 raw.idmap -
echo -en "gid 300 1000" | lxc config set container-2 raw.idmap -
The first id in the line is the Host UID, the second is the ID in the container. The two examples above map the mntShare Host user/group to the user/group at id 1000.
Finally add the disk to the container
lxc config device add container-1 share disk source=/mnt/share path=/mnt/share
- container-1: container name
- share: container new device name
- disk: container new device type
- source: host directory to share
- path: container directory to place share
Note
Because the root user (on unprivileged containers) is actually mapped to a non-0 user on the container, the root user may not have access to do things in the container. If you need this to work, you'll need to configure the mappings appropriately.