Interfaces for Raspberry Pi imager

Raspberry Pi Imager is a desktop application designed to make it easy for users to create SD cards for Pi-like devices. I have made a snap, which requires udisks2 and block-devices in order to operate. Without them it can neither enumerate devices, nor unmount and write to them.

Please can I request autoconnection of udisks2 and block-devices for the imager snap. Snapcraft source at and upstream source at


Given that the purpose of this application is to make image writing easy and accessible to an audience who may not be familiar with Ubuntu and Linux, I am :+1: on granting access to udisks2 and block-devices. Raspberry Pi Image also include guard rails to ensure that only removable storage devices are presented as writable targets.

why is there only one heart to click on !!!


As an aside I wonder if the name imager is a bit generic and whether a name like rpi-imager or similar would be more appropriate?

Anyway, +1 for udisks2 auto-connect, and +1 for use of block-devices but -1 for auto-connect of block-devices - whilst I appreciate this is required for the snap to function, this is a privileged interface and is too powerful to grant auto-connect of IMO - plus the snap could try and detect whether this was available and raise a dialog to the user to prompt manual connection of this interface in the case that it is not connected.

I’m fine changing the name. Raising a dialog to punch the user and ask them to open a terminal to run a command to enable a feature is getting ugly fast. It goes against the point of this app, to make it easy to write SD cards. Makes me sad and cringe every time I have to implement it, frankly. :frowning:

Agreed. If we’re not going to get snapd supporting an easy “yes, let this app do this thing” similar to iOS and Android permission dialogs at point of requirement then we need to be much more liberal in giving permissions to apps until such time as granting permissions is easy. This is not good UX for new or novice users!

1 Like

@popey if imager needs access to block-devices how does it escalate privileges to write to these? Does it use policykit or is there some privileged backend which runs as root?

I have moved the snap to be rpi-imager built from the same git repo as before, as suggested. (they seemed to change the name of the app about an hour after I made mine, and at least once prior to that :slight_smile: - naming things is hard).

Ok, without udisks2 and block-devices, when selecting an SD card, I get this in a loop and the application fails to find an SD card.

Error executing lsblk
Error executing lsblk
Error executing lsblk


This appears to originate here

If I connect block-devices the application operates the same, up until selecting an SD card. Now it’s found, but fails to write. So I added the udisks2 interface. At the point of writing, it asks for the “sudo” password. Not sure how it does that.

I believe that’s using policykit.

Edit: I’ve just looked at their source. They are doing all interaction with the devices through the udisks dbus api, so it is actually udisks that requests the password to authorise access to the raw device (outside confinement) when told by imager to do things to the device.

1 Like

Weirdly, this worked yesterday, but I can’t get it working today. Perhaps I connected something yesterday during my debugging which I haven’t connected today. Now it fails after the policykit prompt to access /dev/mmcblk0, which I suspect is when it’s trying to unmount the card. As this appears in the security log.

= Seccomp =
Time: Mar  6 14:13:28
Log: auid=1000 uid=1000 gid=1000 ses=3 pid=719483 comm="DownloadExtract" exe="/snap/imager/x1/bin/rpi-imager" sig=0 arch=c000003e 166(umount2) compat=0 ip=0x7f65aad768c7 code=0x50000
Syscall: umount2
* add one of 'cifs-mount, network-control' to 'plugs'

So doing some more debugging.

Ok, now I’m baffled. I have udisks2 and others connected, but…


= AppArmor =
Time: Mar  6 14:22:34
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/UDisks2/Manager" interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" name="org.freedesktop.UDisks2" pid=736410 label="snap.rpi-imager.rpi-imager" peer_pid=2805 peer_label="unconfined"
DBus access
* try adding 'udisks2' to 'plugs'

= AppArmor =
Time: Mar  6 14:22:34
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/UDisks2/block_devices/mmcblk0" interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" name="org.freedesktop.UDisks2" pid=736410 label="snap.rpi-imager.rpi-imager" peer_pid=2805 peer_label="unconfined"
DBus access
* try adding 'udisks2' to 'plugs'
$ snap connections rpi-imager 
Interface        Plug                        Slot              Notes
block-devices    rpi-imager:block-devices    :block-devices    manual
cifs-mount       rpi-imager:cifs-mount       :cifs-mount       manual
desktop          rpi-imager:desktop          :desktop          -
desktop-legacy   rpi-imager:desktop-legacy   :desktop-legacy   -
home             rpi-imager:home             :home             -
mount-observe    rpi-imager:mount-observe    -                 -
network          rpi-imager:network          :network          -
network-control  rpi-imager:network-control  :network-control  manual
network-manager  rpi-imager:network-manager  -                 -
opengl           rpi-imager:opengl           :opengl           -
raw-usb          rpi-imager:raw-usb          -                 -
removable-media  rpi-imager:removable-media  -                 -
udisks2          rpi-imager:udisks2          :udisks2          manual
x11              rpi-imager:x11              :x11              -

I’m getting plug blindness. What am I missing? :smiley:

Here’s the script I’m using for testing…

set -eu
sudo snap remove rpi-imager
#snapcraft --use-lxd
#snapcraft remote-build --launchpad-user popey --launchpad-accept-public-upload
sudo snap install rpi-imager_*amd64.snap --dangerous
#sudo snap connect rpi-imager:mount-observe
#sudo snap connect rpi-imager:removable-media
sudo snap connect rpi-imager:udisks2
sudo snap connect rpi-imager:block-devices
sudo snap connect rpi-imager:cifs-mount
#sudo snap connect rpi-imager:network-control
snap run rpi-imager

Using the source at

Slightly less baffled now. i think it’s all down to not being able to unmount the SD card. It works sometimes, because sometimes the SD card happens to not be mounted, which works fine. The moment the SD card is already mounted, that’s what causes the above failure. So we need to perhaps tweak one of the existing interfaces to allow unmounting.

To be clear. I see no way to make this snap work without an interface which allows unmounting.

With the udisks2 interface connected, if you add this to /var/lib/snapd/apparmor/profiles/snap.rpi-imager.rpi-imager:

dbus (send)

and you reload the policy with sudo apparmor_policy -r /var/lib/snapd/apparmor/profiles/snap.rpi-imager.rpi-imager do the application work correctly?

I suspect that the application is falling back to umount/etc itself since udisks2 isn’t working correctly. If we can fix udisks2, my hope is that your application will not need the extra accesses.

This should be fixed in

I assume you mean sudo apparmor_parser and yes, that works!

Thank you.

Thanks for confirming. I’ve now submitted a PR for 2.44 that will hopefully make it in:

@popey - now that udisks2 works, is block-devices still needed?

It still fails without block-devices. Failing to run lsblk

beyond using lsblk it will also need to directly write to the device node at some point in the process to actually write the image to disk (like dd and friends do)

There’s a further issue here. A user on Solus alerted me to a problem with another snap (sosumi) where I use snapctl is-connected (interface) to prompt the user to connect a disconnected interface before continuing.

They get:

error: error running snapctl: Unknown command `is-connected'. Please specify one command of: get, restart, services, set, start or stop

Which is likely because they’re on 2.39.3 as Solus is outdated.

So do we also need to add an assumes: 2.43 to the snapcraft.yaml as an extra guard, to prevent people installing the snap when on <2.43? If so, this will be needed on all snaps which use snapctl is-connected?