Error: Failed to create credentials directory

I’ve just encountered an error for which I can’t find someone elses homework to crib.


$ incus start s26001:llama-cpp-server
Error: Failed to create credentials directory: chown /var/lib/incus/containers/llama-cpp-server/credentials: no such file or directory
Try `incus info --show-log s26001:llama-cpp-server` for more info
kgoetz@L23001:~/source/pyinfra_tests$ incus info --show-log s26001:llama-cpp-server
Name: llama-cpp-server
Description: 
Status: STOPPED
Type: container
Architecture: x86_64
Created: 2026/08/21 17:00 AEST
Last Used: 2026/08/22 21:01 AEST

Snapshots:
+-------------------+-----------------------+------------+----------+
|       Name        |       Taken at        | Expires at | Stateful |
+-------------------+-----------------------+------------+----------+
| software-deployed | 2026/08/22 20:12 AEST |            | NO       |
+-------------------+-----------------------+------------+----------+

Log (lxc.log):


kgoetz@L23001:~

The only reference I have found so far, is the source code at incus/internal/server/instance/drivers/driver_lxc.go at 4770cb07daec2161a85ed9a05647751a789391da · lxc/incus · GitHub .

I don’t see any errors in systemd journal on the server, nor is there anything (at all) in incusd.log. the containers lxc.log only show what is visible above - nothing - and console.log appears to show the console when I last had this container running.

None of my changes in apts history.log or /etc/ lead me to a cause.

Any suggestions on what might have caused this, or how to investigate it further?

What storage driver are you using?

I think its btrfs but I’m not on site to check - I will reply again later once I’ve confirmed.

Okay, if it’s on btrfs or dir, then ls -lh /var/lib/incus/containers/llama-cpp-server/ would be useful to see what’s going on in there.

Thanks for your help @stgraber , sorry it took a while to respond.

I can confirm its btrfs type

root@s26001:~# incus storage list
+---------+--------+-------------+---------+---------+
|  NAME   | DRIVER | DESCRIPTION | USED BY |  STATE  |
+---------+--------+-------------+---------+---------+
| default | btrfs  |             | 4       | CREATED |
+---------+--------+-------------+---------+---------+

hopefully these are of use in debugging

root@s26001:~# df -h /var/lib/incus/containers/llama-cpp-server
Filesystem      Size  Used Avail Use% Mounted on
-               1.6T   62G  1.5T   4% /var/lib/incus/storage-pools/default/containers/llama-cpp-server

root@s26001:~# mount |grep 'sda.*incus'
/dev/sda4 on /incusvol type btrfs (rw,relatime,ssd,discard=async,space_cache=v2,user_subvol_rm_allowed,subvolid=5,subvol=/)
/dev/sda4 on /var/lib/incus/storage-pools/default type btrfs (rw,relatime,ssd,discard=async,space_cache=v2,user_subvol_rm_allowed,subvolid=5,subvol=/)
/dev/sda4 on /var/lib/incus/devices/OperationsCenterAppliance/config.mount type btrfs (ro,relatime,ssd,discard=async,space_cache=v2,user_subvol_rm_allowed,subvolid=256,subvol=/virtual-machines/OperationsCenterAppliance)

root@s26001:~# ls -lha /var/lib/incus/storage-pools/default/containers/llama-cpp-server
total 12K
d--x------ 1 1000000 root   78 Aug 24 19:30 .
drwx--x--x 1 root    root   32 Aug 21 17:00 ..
-r-------- 1 root    root 6.6K Aug 22 21:01 backup.yaml
-rw-r--r-- 1 root    root  529 Aug 20 15:28 metadata.yaml
drwxr-xr-x 1 root    root  216 Aug 21 17:17 rootfs
drwxr-xr-x 1 root    root   42 Aug 20 15:28 templates

Hmm, assuming the problem still occurs, maybe try creating the folder and see if that helps somehow?

Turns out its a quota issue

root@s26001:/var/lib/incus/storage-pools/default/containers/llama-cpp-server# mkdir credentials
mkdir: cannot create directory ‘credentials’: Disk quota exceeded

This is a first for me so I’ll need to go and learn about btfs quotas - and why there is one on this system.

I followed this thread through a couple of layers, seeing similar numbers turning up in different btrfs and incus commands:

root@s26001:~# btrfs subvolume show /incusvol/containers/llama-cpp-server
containers/llama-cpp-server
	Name: 			llama-cpp-server
	UUID: 			d328a442-8c22-6b47-9723-a8681acb73bd
	Parent UUID: 		c0d13312-ebdd-1d4d-8b1f-562c152fe05a
	Received UUID: 		-
	Creation time: 		2026-08-21 17:00:27 +1000
	Subvolume ID: 		258
	Generation: 		7197
	Gen at creation: 	34
	Parent ID: 		5
	Top level ID: 		5
	Flags: 			-
	Send transid: 		0
	Send time: 		2026-08-21 17:00:27 +1000
	Receive transid: 	0
	Receive time: 		-
	Snapshot(s):
				containers-snapshots/llama-cpp-server/software-deployed
	Quota group:		0/258
	  Limit referenced:	27.94GiB
	  Limit exclusive:	-
	  Usage referenced:	27.94GiB
	  Usage exclusive:	13.99GiB
root@s26001:~# incus storage volume info default container/llama-cpp-server
Name: llama-cpp-server
Type: container
Content type: filesystem
Usage: 13.99GiB
Total: 27.94GiB
Created: 2026/08/21 17:00 AEST

Snapshots:
+-------------------+-------------+------------+
|       Name        | Description | Expires at |
+-------------------+-------------+------------+
| software-deployed |             |            |
+-------------------+-------------+------------+
root@s26001:~# btrfs qgroup show /incusvol/
Qgroupid    Referenced    Exclusive   Path
--------    ----------    ---------   ----
0/5           16.00KiB     16.00KiB   <toplevel>
0/256         27.67GiB     27.67GiB   virtual-machines/OperationsCenterAppliance
0/258         27.94GiB     13.99GiB   containers/llama-cpp-server
0/260         19.86GiB      5.92GiB   containers-snapshots/llama-cpp-server/software-deployed
0/263        405.95MiB    405.95MiB   images/1be92a68a456c701326fa0297e0527f44236a502312ff5ebf436aa133fb4f254

and thought maybe i could delete the snapshot to free up space.

ironically no, as there is a file created during the removal process.

root@s26001:~# incus snapshot delete llama-cpp-server software-deployed
Error: Failed to create file "/var/lib/incus/containers/llama-cpp-server/backup.yaml": openat backup.yaml: disk quota exceeded

Can you show the full incus config show --expanded llama-cpp-server?

root@s26001:~# incus config show --expanded llama-cpp-server
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Debian trixie amd64 (20260820_05:24)
  image.os: Debian
  image.release: trixie
  image.serial: '20260820_05:24'
  image.type: squashfs
  image.variant: default
  volatile.base_image: 40003aec47343c52acc324cb46251ac23dcebd9d63817761e302e08825948f76
  volatile.cloud-init.instance-id: b8ab936c-71dc-4c0a-a887-5d06fade8dca
  volatile.eth0.hwaddr: 10:66:6a:38:32:26
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.uuid: 3f682816-9ff1-4e63-9b8f-3b3c824c68fc
  volatile.uuid.generation: 3f682816-9ff1-4e63-9b8f-3b3c824c68fc
devices:
  eth0:
    name: eth0
    nictype: macvlan
    parent: eno1
    type: nic
  nvidia0:
    type: gpu
  root:
    path: /
    pool: default
    size: 30GB
    type: disk
ephemeral: false
profiles:
  - default
stateful: false
description: ""

I’d say try to bump the 30GB to 32GB and see if that sorts it out.

I tried to override the root volume but got a quota error, i also tried with the format suggested in Error modifying LXD VM devices for stateful snapshoting - #3 by mezobari but had the same result.

root@s26001:~# incus config device override llama-cpp-server root size=33GB
Error: Failed to update device "root": Failed to run: btrfs qgroup limit 33000000000 0/258 /var/lib/incus/storage-pools/default/containers/llama-cpp-server: exit status 1 (ERROR: unable to limit requested quota group: Disk quota exceeded)
root@s26001:~# incus config device override llama-cpp-server root size.state=33GB
Error: Failed to update device "root": Failed to run: btrfs qgroup limit 30000000000 0/258 /var/lib/incus/storage-pools/default/containers/llama-cpp-server: exit status 1 (ERROR: unable to limit requested quota group: Disk quota exceeded)

I had a look in system journal but don’t see any messages logged at that time.

In case the issue with btrfs was kernel version specific I rebooted from 6.12.101+deb13-amd64 into 6.12.73+deb13-amd64 but the disk quota issue persists - for root and incus

root@s26001:~# incus config device override llama-cpp-server root size.state=33GB
Error: Failed to write backup file: Failed to create file "/var/lib/incus/containers/llama-cpp-server/backup.yaml": openat backup.yaml: disk quota exceeded
root@s26001:~# mkdir /var/lib/incus/containers/llama-cpp-server/credentials
mkdir: cannot create directory ‘/var/lib/incus/containers/llama-cpp-server/credentials’: Disk quota exceeded

Hmm, okay, then the next obvious option would be to clear up some space in there to get the quota errors to stop so you can then update the quota or at least start it back up.

You can either look for anything obvious to clear directly through /var/lib/incus/containers/llama-cpp-server/rootfs/ or you can use incus file mount to mount the container’s filesystem on any system that can interact with Incus.

Good candidates for quickly clearing space would be /var/cache/apt/archives/ or stuff under /var/log/

I found a 5GB cache directory in roots home and that freed up space which allowed me to start up. The rootfs directory reports as being 29GB (probably 30 if i had used du --si).

Thanks for your help tracking it down @stgraber !