adding a TrueNAS VM share to unprivelidged LXC

[chenks]

Just a thought that might suit your needs.

I know you said:

But: How about yes setting up the NFS share as a Proxmox backend storage as a directory/rootdir type (only) & then bind mount that directory to the unprivileged LXC - maybe that will work for you.

How is that done? And how does it differ to mounting in fstab?

 

[gfngfn256]

Basically you'd start again.

So you would comment out that entry you made from the fstab , making sure its no longer mounted & that directory is empty. Maybe reboot the node? (Proxmox will take care of the mounting/fstab on its own).

Then you'd edit the /etc/pve/storage.cfg to add that NFS share to Proxmox Storage, selecting only the rootdir type for content.

So maybe something like this in your case:

nfs: truenas_downloads
        path /mnt/pve/truenas_downloads
        server 192.168.50.16
        export /mnt/prox-pool/downloads
        options vers=3,soft
        content rootdir

Then you'd try creating a bind mount from a subdirectory within /mnt/pve/truenas_downloads to the LXC as above

See here for the PVE Wiki on the NFS backend storage.

I must point out, I've never used it, and you may also have to see how it works out with timings (your original problem) since the NFS share is in fact from a Proxmox VM.

Good luck.

 

[chenks]

Basically you'd start again.

So you would comment out that entry you made from the fstab , making sure its no longer mounted & that directory is empty. Maybe reboot the node? (Proxmox will take care of the mounting/fstab on its own).

Then you'd edit the /etc/pve/storage.cfg to add that NFS share to Proxmox Storage, selecting only the rootdir type for content.

So maybe something like this in your case:

nfs: truenas_downloads
        path /mnt/pve/truenas_downloads
        server 192.168.50.16
        export /mnt/prox-pool/downloads
        options vers=3,soft
        content rootdir

Then you'd try creating a bind mount from a subdirectory within /mnt/pve/truenas_downloads to the LXC as above

See here for the PVE Wiki on the NFS backend storage.

I must point out, I've never used it, and you may also have to see how it works out with timings (your original problem) since the NFS share is in fact from a Proxmox VM.

Good luck.

i'll look into that, but if there isn't a way to delay the mount (to wait for the VM to boot) then that won't be an option.

the method currently being used should work though, so find the root cause of the issue is valuable.

 

[gfngfn256]

but if there isn't a way to delay the mount

Proxmox, will also edit the fstab on it's own, so you won't have less options than before. In general it should handle NFS correctly.

the method currently being used should work though

Not exactly. An LXC unprivileged container, has that name for a reason. Its supposed to cut off the containers namespace & permissions from the host it's running on, up to the point that the container is (supposed to be) blind regarding the host. A bind mount is basically trying to pierce a hole from one to the other. NFS shares in general can be rather flaky - search these forums & general Web. You'll find plenty results of people trying to achieve your exact endpoint - with varying success/failure.

On a privileged container, you can allow NFS from within the GUI, but on an unprivileged one you can't. This is by design for security reasons as above. So as you see, Proxmox by design does not want to do what you are trying. Your failure, probably proves that this security is somewhat robust.

I myself, would not use an unprivileged LXC, but the choice is yours. You could also just create a VM & be finished with this.

One other thing; Assuming apparmor is the one you are up against, you may want to go down that rabbit-hole.

 

[chenks]

On a privileged container, you can allow NFS from within the GUI, but on an unprivileged one you can't. This is by design for security reasons as above. So as you see, Proxmox by design does not want to do what you are trying. Your failure, probably proves that this security is somewhat robust.

i could just use smb instead of NFS as that works perfectly. however, from what i've seen, NFS performs a little better than smb.