itviewer@JackMa:~$ incus start ubuntu22
Error: Failed to run: /opt/incus/bin/incusd forkstart ubuntu22 /var/lib/incus/containers /run/incus/ubuntu22/lxc.conf: exit status 1
Try `incus info --show-log ubuntu22` for more info
itviewer@JackMa:~$ incus info --show-log ubuntu22
Name: ubuntu22
Description: dev
Status: STOPPED
Type: container
Architecture: x86_64
Created: 2024/11/19 21:28 CST
Last Used: 2025/11/28 20:17 CST
Log:
lxc ubuntu22 20251128121708.289 ERROR utils - ../src/lxc/utils.c:safe_mount:1334 - Permission denied - Failed to mount "/var/lib/incus/containers/ubuntu22/credentials" onto "/opt/incus/lib/lxc/rootfs/dev/.incus-systemd-credentials"
lxc ubuntu22 20251128121708.289 ERROR conf - ../src/lxc/conf.c:mount_entry:2202 - Permission denied - Failed to mount "/var/lib/incus/containers/ubuntu22/credentials" on "/opt/incus/lib/lxc/rootfs/dev/.incus-systemd-credentials"
lxc ubuntu22 20251128121708.289 ERROR conf - ../src/lxc/conf.c:lxc_setup:3908 - Failed to setup mount entries
lxc ubuntu22 20251128121708.289 ERROR start - ../src/lxc/start.c:do_start:1273 - Failed to setup container "ubuntu22"
lxc ubuntu22 20251128121708.289 ERROR sync - ../src/lxc/sync.c:sync_wait:34 - An error occurred in another process (expected sequence number 3)
lxc ubuntu22 20251128121708.293 WARN network - ../src/lxc/network.c:lxc_delete_network_priv:3674 - Failed to rename interface with index 0 from "eth0" to its initial name "veth9d88c9aa"
lxc ubuntu22 20251128121708.293 ERROR start - ../src/lxc/start.c:__lxc_start:2119 - Failed to spawn container "ubuntu22"
lxc ubuntu22 20251128121708.293 WARN start - ../src/lxc/start.c:lxc_abort:1037 - No such process - Failed to send SIGKILL via pidfd 17 for process 6692
lxc ubuntu22 20251128121708.293 ERROR lxccontainer - ../src/lxc/lxccontainer.c:wait_on_daemonized_start:832 - Received container state "ABORTING" instead of "RUNNING"
lxc 20251128121708.344 ERROR af_unix - ../src/lxc/af_unix.c:lxc_abstract_unix_recv_fds_iov:218 - 连接被对方重置 - Failed to receive response
lxc 20251128121708.344 ERROR commands - ../src/lxc/commands.c:lxc_cmd_rsp_recv_fds:128 - Failed to receive file descriptors for command "get_init_pid"
I haven’t used incus for a while, and when I tried to start a container today, I encountered an error. I couldn’t start any container, even though I could create a new container. After successfully creating the container, starting it immediately failed.
root@v1:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.3 LTS
Release: 24.04
Codename: noble
root@v1:~# uname -a
Linux v1 6.8.0-88-generic #89-Ubuntu SMP PREEMPT_DYNAMIC Sat Oct 11 01:02:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
root@v1:~# incus admin init
Would you like to use clustering? (yes/no) [default=no]:
Do you want to configure a new storage pool? (yes/no) [default=yes]:
Name of the new storage pool [default=default]:
Name of the storage backend to use (btrfs, dir, truenas) [default=btrfs]:
Create a new BTRFS pool? (yes/no) [default=yes]:
Would you like to use an existing empty block device (e.g. a disk or partition)? (yes/no) [default=no]:
Size in GiB of the new loop device (1GiB minimum) [default=5GiB]:
Would you like to create a new local network bridge? (yes/no) [default=yes]:
What should the new bridge be called? [default=incusbr0]:
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
Would you like the server to be available over the network? (yes/no) [default=no]:
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]:
Would you like a YAML "init" preseed to be printed? (yes/no) [default=no]:
root@v1:~# incus launch images:debian/13 d13
Launching d13
root@v1:~# incus list
+------+---------+-----------------------+------------------------------------------------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+---------+-----------------------+------------------------------------------------+-----------+-----------+
| d13 | RUNNING | 10.247.145.176 (eth0) | fd42:509d:44b7:50a5:1266:6aff:fe53:b136 (eth0) | CONTAINER | 0 |
+------+---------+-----------------------+------------------------------------------------+-----------+-----------+
root@v1:~#
I repeated your command above using the loop device without any problems. I’m using a separate btrfs partition on a physical disk. Is there any difference?
itviewer@JackMa:~$ incus admin init
Would you like to use clustering? (yes/no) [default=no]:
Do you want to configure a new storage pool? (yes/no) [default=yes]:
Name of the new storage pool [default=default]:
Name of the storage backend to use (dir, truenas, btrfs) [default=btrfs]:
Create a new BTRFS pool? (yes/no) [default=yes]:
Would you like to use an existing empty block device (e.g. a disk or partition)? (yes/no) [default=no]:
Size in GiB of the new loop device (1GiB minimum) [default=30GiB]:
Would you like to create a new local network bridge? (yes/no) [default=yes]:
What should the new bridge be called? [default=incusbr0]:
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
Would you like the server to be available over the network? (yes/no) [default=no]:
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]:
Would you like a YAML "init" preseed to be printed? (yes/no) [default=no]:
itviewer@JackMa:~$ incus launch images:alpine/edge alpine
Launching alpine
itviewer@JackMa:~$ incus list
+--------+---------+-----------------------+------------------------------------------------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+--------+---------+-----------------------+------------------------------------------------+-----------+-----------+
| alpine | RUNNING | 10.101.101.159 (eth0) | fd42:66c7:77d0:477d:1266:6aff:fe1f:a3f5 (eth0) | CONTAINER | 0 |
+--------+---------+-----------------------+------------------------------------------------+-----------+-----------+
The btrfs partition is mounted using the above configuration in /etc/fstab. And the btrfs partition has been deleted and reformatted multiple times to ensure that no previous content has affected it.
The error message your first posted answers that. The systemd credentials feature requires the container to be able to bind-mount a directory that’s stored within its volume. The container runs unprivileged, so it can’t cross through a 0700 folder which is what your btrfs filesystem’s root directory is set to.
The problem seems to have been found: I’ve been formatting the partition as btrfs using the system’s built-in graphical disk utility (gnome-disks). The problem disappears when I switch to mkfs.btrfs or have incus create a clean storage pool and format the partition.
If you’re interested or just for fun, you can try formatting the partition using the gnome-disks, to see if the problem can be reproduced.
Is it possible that gnome-disks uses the older btrfs tool, and while incus 6.17 is compatible with this format, but versions after 6.18 only support the latest btrfs format?
My guess is that gnome-disks sees that you’re running this from a user session and tries to be helpful in setting the owner and permissions at the root of the new filesystem so that only your user can access it.
That makes sense if you’re formatting a USB stick, doesn’t make as much sense if you’re formatting system storage.