Our Snap is built using –devmode and runs as root. It is not intended for the Snap Store.
It manages custom USB devices. We have the ability on our device to disable power to any USB port. However, it appears Linux does not de-enumerate when power is disable and one must trigger a udev rule to fully remove the device from Ubuntu Core.
The command to do this is: udevadm trigger --action=remove /sys/bus/usb/devices/2-1.4.6/
However, when executing this command inside the Snap I get ‘Running in chroot, ignoring request’ whether I use sudo or not.
Per googling, supposedly if you add a hardware-observe and/or snapd-control plug it should provide privileges so this can work – but none of this works? I still get the chroot errror. I already have raw-usb plug
How can I provide my Snap privs it needs to run udevadm trigger then?
Appreciate any help,
Will
It is not a snap privilege issue, but a systemd behavior:
}
int trigger_main(int argc, char *argv[], void *userdata) {
_cleanup_(sd_device_enumerator_unrefp) sd_device_enumerator *e = NULL;
_cleanup_(sd_device_monitor_unrefp) sd_device_monitor *m = NULL;
_cleanup_(sd_event_unrefp) sd_event *event = NULL;
_cleanup_set_free_ Set *settle_ids = NULL;
int r;
if (running_in_chroot() > 0) {
log_info("Running in chroot, ignoring request.");
return 0;
}
r = parse_argv(argc, argv);
if (r <= 0)
return r;
r = sd_device_enumerator_new(&e);
if (r < 0)
return r;
Try setting the SYSTEMD_IN_CHROOT environment variable to false before running that command:
int running_in_userns(void) {
int r;
r = namespace_is_init(NAMESPACE_USER);
if (r < 0)
return log_debug_errno(r, "Failed to test if in root user namespace, ignoring: %m");
return !r;
}
int running_in_chroot(void) {
int r;
/* If we're PID1, /proc may not be mounted (and most likely we're not in a chroot). But PID1 will
* mount /proc, so all other programs can assume that if /proc is *not* available, we're in some
* chroot. */
r = getenv_bool("SYSTEMD_IN_CHROOT");
if (r >= 0)
return r > 0;
if (r != -ENXIO)
Lin-Buo-Ren:
SYSTEMD_IN_CHROOT
Thank you for responding so quickly. I tried the following all with same failure
(poller) root@thio-lab-0:/var/snap/thio/current/thio/utils# SYSTEMD_IN_CHROOT=false;udevadm trigger --action=remove /sys/bus/usb/devices/2-1.4.6/
Running in chroot, ignoring request.
(poller) root@thio-lab-0:/var/snap/thio/current/thio/utils# export SYSTEMD_IN_CHROOT=false;sudo udevadm trigger --action=remove /sys/bus/usb/devices/2-1.4.6/
Running in chroot, ignoring request.
(poller) root@thio-lab-0:/var/snap/thio/current/thio/utils# export SYSTEMD_IN_CHROOT=0;sudo udevadm trigger --action=remove /sys/bus/usb/devices/2-1.4.6/
Running in chroot, ignoring request.
(poller) root@thio-lab-0:/var/snap/thio/current/thio/utils# export SYSTEMD_IN_CHROOT=0;udevadm trigger --action=remove /sys/bus/usb/devices/2-1.4.6/
Running in chroot, ignoring request.
Note:
(poller) root@thio-lab-0:/var/snap/thio/current/thio/utils# whoami
root
abeato
February 26, 2026, 7:01pm
4
To ensure that udevadm sees the env var you need something like:
sudo SYSTEMD_IN_CHROOT=0 udevadm trigger --action=remove /sys/bus/usb/devices/2-1.4.6/
Then it would be interesting to check if you get apparmor denials to see what interfaces you would need to operate confined.
Yes. I did try that too. No luck. No change.
The workaround I came up with is to unbind by:
echo ‘{busNum}.{portNum}’ | sudo tee /sys/bus/usb/drivers/usb/unbind
This worked inside a snap.
