New container will not allow me to mount disk with shift=true set, despite other containers allowing me to do so

So, I have a bunch of containers on a host. It’s running Ubuntu Server 22.04. We are keeping the configuration and data for the application we’re running in various zfs datasets that are being mounted into the containers. We want the containers to have shifted UIDs, but the disks to be mounted in to not be, because it will allow us to move them to other containers more easily, and given that some of these datasets have tens of millions of files in them it makes more sense to dictate UID/GIDs to the system than to have the system impose them on the datasets, because moving them on the dataset for some of them can take well over a week.

So currently, we have a bunch of containers whose disk entry in their config looks like this:

devices:
  bank-db-lib:
    path: /external/var-lib-mysql
    required: "false"
    shift: "true"
    source: /zomg/bank-db-var-lib-mysql
    type: disk

So, I have created a new container: lxc init ubuntu:22.04 jnu-db0

And I have added devices to it:

lxc config device add jnu-db0 jnu-db-etc disk source=/zombo/jnu-db-etc-mysql path=/external/etc-mysql shift=true required=false
lxc config device add jnu-db0 jnu-db-lib disk source=/zombo/jnu-db-var-lib-mysql path=/external/var-lib-mysql shift=true required=false
lxc config device add jnu-db0 jnu-db-log disk source=/zombo/jnu-db-var-log-mysql path=/external/var-log-mysql shift=true required=false

all of which completed successfully. However, when I try to start the new container I get: Error: Failed to setup device mount "jnu-db-etc": idmapping abilities are required but aren't supported on system

I have tried a few different approaches to this but I always end up here, despite the fact that these configurations seem to be functioning just fine on the other containers on the system. Where should I be looking to figure out why this isn’t working the way I expect it to?

Is this because the other containers have a slightly older version of ubuntu 22.04? i.e.

  image.architecture: amd64
  image.description: ubuntu 22.04 LTS amd64 (release) (20230712)
  image.label: release
  image.os: ubuntu
  image.release: jammy
  image.serial: "20230712"
  image.type: squashfs
  image.version: "22.04"

vs

  image.architecture: amd64
  image.description: ubuntu 22.04 LTS amd64 (release) (20240426)
  image.label: release
  image.os: ubuntu
  image.release: jammy
  image.serial: "20240426"
  image.type: squashfs
  image.version: "22.04"

If there’s any other information you should need please don’t hesitate to ask!

Cheers,

Jack

This will be caused by a combination of your host OS’s kernel and the filesystem the container is running on.

What kernel are you running?

Yeah, it was definitely a kernel problem. I worked around it by selecting a very specific ubuntu 22 image to install on that host, and recently (a week ago) I got the service window to be able to update it, so that problem is firmly in the rear window now. I’m running 6.5 now, and I think the likeliest one that was baked in was 5.15.0-86-generic. Filesystem was zfs.

Kinda funny you posted, you have no idea how happy I was when I finally got to resolve the issue last week.

2 Likes