Unable to install MaaS snap on LXD

Hi all. I’m trying to install maas via snap on LXD per the docs:

When installing on LXD with Ubuntu 20.04, I receive the following error:

$ sudo snap install maas
error: cannot perform the following tasks:
- Run install hook of "maas" snap if present (run hook "install": chown: changing ownership of '/var/snap/maas/common/log': Invalid argument)

I’ve tried several things to resolve this, with the same error each time, such as:

  • Trying to install the snap as root, or as a regular user (with sudo)
  • Trying with different security confinement/mode (like --devmode)

I do see one user reported the same error here for an arm64 snap install whereas I am testing on x86_64 Linux (LXD on NixOS):

To try and debug, if I download the snap, unsquash it, comment out the one bash line in the install hook script which is throwing the error, it then seems to complete the install successfully (although I have no idea if it will actually work properly – haven’t tested that far yet):

$ snap download maas
Fetching snap "maas"
Fetching assertions for "maas"
Install the snap with:
   snap ack maas_8980.assert
   snap install maas_8980.snap

$ sudo unsquashfs maas_8980.snap 
Parallel unsquashfs: Using 12 processors
26365 inodes (27330 blocks) to write
created 23305 files
created 6747 directories
created 2851 symlinks
created 0 devices
created 0 fifos

# Comment out the failing `chown` command on line 31 of the `snap/hooks/install` script:
# 29 if [ ! -d "$SNAP_COMMON/log" ]; then
# 30     mkdir -m 775 "$SNAP_COMMON/log"
# 31     chown snap_daemon "$SNAP_COMMON/log"
# 32 fi
$ sudo sed -i 's|chown snap_daemon "$SNAP_COMMON/log"|# chown snap_daemon "$SNAP_COMMON/log"|g' squashfs-root/snap/hooks/install

$ sudo snap try squashfs-root/
maas 2.8.2-8577-g.a3e674063 mounted from /home/maasuser/test/squashfs-root

$ snap list
Name      Version                 Rev    Tracking       Publisher   Notes
core18    20200929                1932   latest/stable  canonical✓  base
lxd       4.0.3                   16922  4.0/stable/…   canonical✓  -
maas      2.8.2-8577-g.a3e674063  x2     -              -           try
maas-cli  0.6.5                   13     latest/stable  canonical✓  -
ripgrep   12.1.0                  9      latest/stable  icey        classic
snapd     2.47.1                  9721   latest/stable  canonical✓  snapd

The chown command fails on:

chown snap_daemon $FILE

The snap_daemon user is uid 584788, and the lxc container appears to only recognize UIDs to 65535 by default.

How can I get the container to allow the snap_daemon UID of 584788 to be allowed? In my case, snap exists inside the container only as the host OS is NixOS without snap.

When stracing chown snap_daemon $FILE, an “Invalid argument” error is thrown for any UIDs larger than 65535:

fchownat(AT_FDCWD, "test", 584788, -1, 0) = -1 EINVAL (Invalid argument)

It looks like maybe I can solve this by expanding the uid Maprange to allow uid 584788 with something like: “security.idmap.size”, but so far no luck:

Error: Failed to get ID map: Not enough uid/gid available for the container

Anyone have any ideas on why this error is happening and how to resolve it other than the script hack to comment the offending chown line out above?

After reading more and getting a better understanding of LXD uid mapping, just changing the following on my host system seems enough to resolve this:

# Modify the default root user subuid mapping on my system 
# to a larger range which includes the UID of the snap_daemon user: 584788
sed -i 's/root:1000000:65536/root:1000000:655360/g' /etc/subuid

# Restart the LXD daemon
systemctl restart lxd.service

# Re-create a fresh container to pick up the new map range
lxc delete --force maas
lxc launch ubuntu:20.04 maas

# Continue with installing maas in the LXD per the docs

If the snap of mass-test-db is also to be installed, the same approach above can also be applied to the /etc/subgid file to prevent similar errors with that snap during install.


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.