USB devices "source" path

Is there any way I can configure privileged or something like that so that I can know this is working instead of trying to debug permission issue without any information ?

privileged turns on a whole bunch of extra restrictions so it’s likely to make things worse.

What happens when you set mode: 0666?

Same, tried a couple of combinations but no luck.

stgraber@castiana:~ (incus:dev/default)$ incus config show c1
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Debian trixie amd64 (20251106_05:24)
  image.os: Debian
  image.release: trixie
  image.serial: "20251106_05:24"
  image.type: squashfs
  image.variant: default
  volatile.base_image: 8238bf40b3ee01a9d75520ad1b769ac124c59fa05402a38dc6a0787f4fcb525d
  volatile.cloud-init.instance-id: 11891993-4d53-43ef-a3b6-303b49822133
  volatile.eth0.hwaddr: 10:66:6a:c4:2a:df
  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: STOPPED
  volatile.last_state.ready: "false"
  volatile.uuid: 233beedd-5581-4a9b-b8aa-b2c5ef6b4009
  volatile.uuid.generation: 233beedd-5581-4a9b-b8aa-b2c5ef6b4009
devices:
  usb:
    path: /dev/zwave
    source: /dev/serial/by-id/usb-QEMU_QEMU_USB_SERIAL_1-0000:00:01.0:00.6-4-if00-port0
    type: unix-char
ephemeral: false
profiles:
- default
stateful: false
description: ""
stgraber@castiana:~ (incus:dev/default)$ incus start c1
stgraber@castiana:~ (incus:dev/default)$ incus exec c1 bash
root@c1:~# ls -lh /dev/zwave 
crw-rw---- 1 root root 188, 0 Nov 20 03:27 /dev/zwave
root@c1:~# cat /dev/zwave
^C
root@c1:~# echo foo > /dev/zwave
root@c1:~# 

Interesting …

derek@dmbr incus % ./incus config show debian-container             
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Debian bookworm amd64 (20251116_05:24)
  image.os: Debian
  image.release: bookworm
  image.serial: "20251116_05:24"
  image.type: squashfs
  image.variant: default
  volatile.base_image: 31360b27eada7442ee1f9f6609ac6ee54a888022046d65e0b2caffb7f7fc2036
  volatile.cloud-init.instance-id: f69cd359-5f1e-41fe-9a19-4f240e1bf549
  volatile.eth0.host_name: vethf07b9be8
  volatile.eth0.hwaddr: 10:66:6a:59:b7:6b
  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.last_state.ready: "false"
  volatile.uuid: c63f7ebf-733e-4559-953c-c4743f11f82f
  volatile.uuid.generation: c63f7ebf-733e-4559-953c-c4743f11f82f
devices:
  tmp-dev:
    path: /mnt/dev
    recursive: "true"
    source: /dev
    type: disk
  zwave:
    path: /dev/zwave
    source: /dev/serial/by-id/usb-0658_0200-if00
    type: unix-char
ephemeral: false
profiles:
- default
stateful: false
description: ""
derek@dmbr incus % 
derek@dmbr incus % 
derek@dmbr incus % incus exec debian-container bash
zsh: command not found: incus
derek@dmbr incus % ./incus exec debian-container bash
root@debian-container:~# cat /dev/zwave^C
root@debian-container:~# ls -la /dev/zwave 
crw-rw---- 1 root root 166, 1 Nov 20 03:40 /dev/zwave
root@debian-container:~# echo foo > /dev/zwave
bash: /dev/zwave: Permission denied

Can you show ls -lh /mnt/dev? I wonder if there’s something weird with the permissions there.

After a reboot of the host, everything is working fine…
Possible that the fix required a reboot of the host ?

Actually, yes. The fix can only become properly active if Incus itself gets restarted when no instances are running. That doesn’t necessarily mean a clean startup on boot, but that would be the easy way to meet that condition.