Potential issue when launching containers with custom root mount options

Incus
1

I am using Incus version 6.16 installed from the Zabbly repository. The host OS is Ubuntu 24.04.3. Incus backing storage for containers and images is Ceph RBD.

The goal is to launch a container to run Samba Active Directory Domain Controller, which as far as I understand requires the filesystem to be mounted with options acl and user_xattr.

So I tried:

incus launch images:ubuntu/24.04 addc01 –network incus-ovn –storage incus_rbd –device root,initial.block.filesystem=ext4 –device root,initial.block.mount_options=“rw,relatime,discard,stripe=16,acl,user_xattr”

Options “rw,relatime,discard,stripe=16” were added because they seem to be applied by default when launching other Ubuntu containers.

Verifying:

incus config show addc01

architecture: x86_64
config:
 
 <INFORMATION_OMITTED_FOR_BREVITY>
 
devices:
  eth0:
    name: eth0
    network: incus-ovn
    type: nic
  root:
    initial.block.filesystem: ext4
    initial.block.mount_options: rw,relatime,discard,stripe=16,acl,user_xattr
    path: /
    pool: incus_rbd
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

However, inside the container:

root@addc01:~# mount
/dev/rbd0 on / type ext4 (rw,relatime,idmapped,discard,stripe=16)

What am I missing? Should I first create the storage volume and then attach it during instance creation?

Thanks.

2

My guess is that those are default options so they don’t appear in the mount entry as no change happened from the default.

Here is an example outside of Incus:

root@castiana:~# mount /dev/zvol/castiana/test /mnt/ -o rw,relatime,discard,stripe=16,acl,user_xattr
root@castiana:~# cat /proc/mounts | grep /mnt
/dev/zd16 /mnt ext4 rw,relatime,discard,stripe=16 0 0
root@castiana:~#
3

Oh, I see. As the AD provision kept failing, I assumed this might be the issue. Well, must be something else thern. Thanks.

4

Is there any restriction in the use of extended attributes in containers? For example (these commands come from the samba wiki, for the purpose of testing xattr support):

root@addc04:~# touch test.txt
root@addc04:~# setfattr -n user.test -v test test.txt
root@addc04:~# setfattr -n security.test -v test2 test.txt
setfattr: test.txt: Operation not permitted

This is an unpriviledged container running ubuntu 24.04

5

Might be worth trying Instance options - Incus documentation

6

Thanks. I tried setting security.syscalls.intercept.setxattr to true, but:

root@addc04:/mnt# setfattr -n security.test -v test2 test.txt
setfattr: test.txt: Operation not permitted

Digging deeper in the documentation, I found the following:

setxattr

The setxattr system call is used to set extended attributes on files.

The attributes which are handled by this currently are:

  • trusted.overlay.opaque (overlayfs directory whiteout)

Does this mean that it does not address the scenario of setting random attributes to files?

thanks.

7

Ah yeah, security.XYZ is a very dangerous part of the xattr space, so not something we’d want to blindly escalate privilege on.