adding a TrueNAS VM share to unprivelidged LXC

[chenks]

Maybe try Option 3, Point 7 from this post.

yep that made no difference, the permissions mentioned had already been applied.
also, if it was those permissions i would have expected it to still mount it but just give a "permission denied" when trying to access it.

i wouldn't expect the LXC itself to fail to boot due to a mount point permission issue?

 

[gfngfn256]

i wouldn't expect the LXC itself to fail to boot due to a mount point permission issue?

I agree, that usually that should be the case. Also, I already noted above that your container appears to start & shutdown.

I note that you have in your LXC config keyctl=1 - can you try & set that to keyctl=0 . I know you may need it for docker use - but that setting can have implications when it comes to permissions. If you don't want to mess with the config of that LXC, why not spin up a new vanilla Debian LXC with defaults (which includes the keyctl off by default) - & see if you can then mount your share within it.

 

[chenks]

I note that you have in your LXC config keyctl=1 - can you try & set that to keyctl=0 . I know you may need it for docker use - but that setting can have implications when it comes to permissions. If you don't want to mess with the config of that LXC, why not spin up a new vanilla Debian LXC with defaults (which includes the keyctl off by default) - & see if you can then mount your share within it.

this LXC doesn't use docker, it's a single appliance LXC so i can try that and see what happens.

i am also in the process of creating a blank debian 12 LXC to test it on also.

 

[chenks]

I note that you have in your LXC config keyctl=1 - can you try & set that to keyctl=0 . I know you may need it for docker use - but that setting can have implications when it comes to permissions. If you don't want to mess with the config of that LXC, why not spin up a new vanilla Debian LXC with defaults (which includes the keyctl off by default) - & see if you can then mount your share within it.

update

clean debian install keyctl=0

same end result - LXC starts then fails and stops.

 

[gfngfn256]

On that clean Debian LXC - can you try setting a static IP with GW - within the same NW as the TrueNAS share.
I'm thinking that maybe that TrueNAS share is somehow limited to an IP range.

 

[chenks]

On that clean Debian LXC - can you try setting a static IP with GW - within the same NW as the TrueNAS share.
I'm thinking that maybe that TrueNAS share is somehow limited to an IP range.

the NFS share in truenas doesn't have any network restrictions on it.
both truenas and the pve (and containers) are on the same network 192.168.50.x

 

[gfngfn256]

I'd still try it. Can you show ip a output for the LXC.
I also note that you have firewall off in LXC settings. That is not the default. Did you have a specific reason for this?

 

[chenks]

I'd still try it. Can you show ip a output for the LXC.

truenas IP is 192.168.50.16

the samba share that does work with no issues is 192.168.50.2

debian LXC 192.168.50.176
the original LXC 192.168.50.13

root@debian:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0@if63: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:9f:a4:45 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.50.176/24 brd 192.168.50.255 scope global dynamic eth0
       valid_lft 7195sec preferred_lft 7195sec
    inet6 fd2e:6f86:8fea:641:be24:11ff:fe9f:a445/64 scope global dynamic mngtmpaddr
       valid_lft 1800sec preferred_lft 1800sec
    inet6 fe80::be24:11ff:fe9f:a445/64 scope link
       valid_lft forever preferred_lft forever
root@debian:~#

I also note that you have firewall off in LXC settings. That is not the default. Did you have a specific reason for this?

that LXC was created using one of tteck's scripts.
there is no need for any firewall settings on the LXC itself, my opnsense firewall deals with the firewall.

 

[gfngfn256]

valid_lft 7195sec preferred_lft 7195sec

Why have those values been set? (I'm also not sure which LXC these refer to).

Could you please spin up a new Debian LXC, NOT using any script, using the debian-12-standard template included in Proxmox. I'm assuming your environment is fully updated. In that LXC set a static IP with GW - within the same NW as the TrueNAS share.

 

[chenks]

In that LXC set a static IP with GW

what does "with GW" mean?
pve is not responsibe for assiging any LAN IPs, it's all done via a separate opensense firewall/router, of which there is only 1 network of 192.168.50.x

 

[chenks]

another fresh debian 12 container - using the pve template.
using a DHCP assigned IPv4 address from opnsense.

root@debtest:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0@if68: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:fe:87:43 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.50.177/24 brd 192.168.50.255 scope global dynamic eth0
       valid_lft 6936sec preferred_lft 6936sec
    inet6 fd2e:6f86:8fea:641:be24:11ff:fefe:8743/64 scope global dynamic mngtmpaddr
       valid_lft 1732sec preferred_lft 1732sec
    inet6 fe80::be24:11ff:fefe:8743/64 scope link
       valid_lft forever preferred_lft forever
root@debtest:~#

added the bind mount point to the conf file, rebooted the LXC and this also produces the same error when booting.

arch: amd64
cores: 2
features: nesting=1
hostname: debtest
memory: 2048
mp0: /mnt/truenas_downloads,mp=/downloads
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:FE:87:43,ip=dhcp,type=veth
ostype: debian
rootfs: local-lvm:vm-115-disk-0,size=8G
swap: 512
unprivileged: 1

run_buffer: 571 Script exited with status 13
lxc_init: 845 Failed to run lxc.hook.pre-start for container "115"
__lxc_start: 2034 Failed to initialize container "115"
TASK ERROR: startup for container '115' failed

 

[gfngfn256]

GW stands for gateway.
In your case I imagine that is the IP address of that opensense firewall/router. But you will need to check.

So in the CT creation Wizard of Proxmox, on the Network tab (the sixth after Memory), you will set IPv4 to static (again that is default), you will enter the desired IPv4 address (TOGETHER with the CIDR after a slash), you'll then enter the Gateway (IPv4) underneath that.

 

[chenks]

So in the CT creation Wizard of Proxmox, on the Network tab (the sixth after Memory), you will set IPv4 to static (again that is default), you will enter the desired IPv4 address (TOGETHER with the CIDR after a slash), you'll then enter the Gateway (IPv4) underneath that.

i don't want pve assigning any IP addresses, it is all done via opnsense.
and if i need an LXC to have a static IP i assign one within opnsense.

 

[gfngfn256]

i don't want pve assigning any IP addresses

How does the PVE host itself have a static IP address?

Anyway, each to his own. I would try what I have suggested. Do as you wish.

The logic behind my thinking is, that the time/limits taken for that DHCP to be allocated on LXC startup is affecting that TrueNAS bind mountpoint share.

 

[chenks]

How does the PVE host itself have a static IP address?

via an static IP assigned by opnsense.

The logic behind my thinking is, that the time/limits taken for that DHCP to be allocated on LXC startup is affecting that TrueNAS bind mountpoint share.

but wouldn't that also affect samba shares?
these mount as they should with no errors.

anyway, i just tried what you suggested, set a static IP within the LXC (using a IP that is not in the DHCP range).
rebooted LXC to confirm using new IP.
shutdown LXC, set the mount point in conf file.
restarted LXC and it failed again with the same error.

this would conclude it's not a network issue.

 

[gfngfn256]

via an static IP assigned by opnsense.

Also not recommended.

but wouldn't that also affect samba shares?

Not necessarily.


Anyway - Just try my suggestion.

 

[chenks]

Anyway - Just try my suggestion.

i did, see edit to original post

 

[gfngfn256]

Well - I'm pretty much out of suggestions then.
Have you checked that those TrueNAS shares are accessible from a different client bare-metal or VM?

 

[chenks]

Have you checked that those TrueNAS shares are accessible from a different client bare-metal or VM?

yes they are full accessible from my windows laptop.
they are fully accessible from the pve host itself (mounted via fstab)
they are fully accessible from a windows server VM





i've just noticed that the smbshare (which is the one that does work) has 100000/110000 for uid/gid, but the others have root/root.
could that be the reason? again if it was simply a permissions issue i wouldn't expect the LXC to fail to boot, i'd expect it to mount and then just give an error when trying to access it within the LXC

edit - no that also made on difference, i set the user@group to be the same as the smbshare and the same error occured.

 

[gfngfn256]

Just a thought that might suit your needs.

I know you said:

i don't want to add it as a pve storage location though as i'm not using it for container/template etc storage.

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.