Request auto connect for strawberry


Strawberry needs alsa, udisks2 and network-manager to be connected for all features to function properly.

The snap is here:

The source is in the official repository here:

network-manager is needed for dbus to avoid the following errors:
_logging_message__21:16:57.763 WARN unknown propsReply “An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=”:1.72" (uid=1000 pid=1795 comm="/snap/strawberry/x1/usr/bin/strawberry " label=“snap.strawberry.strawberry (enforce)”) interface=“org.freedesktop.DBus.Properties” member=“GetAll” error name="(unset)" requested_reply=“0” destination=“org.freedesktop.NetworkManager” (uid=0 pid=609 comm="/usr/sbin/NetworkManager --no-daemon " label=“unconfined”)"

alsa is needed for the device finder to locate devices for direct output to alsa, otherwise no devices are listed.

udisks2 is needed for the devices support, copying songs to udisks2 mounted devices:

21:16:58.199 WARN  Udisks2Lister:175                Error enumerating udisks2 devices: "org.freedesktop.DBus.Error.AccessDenied" "An AppArmor policy prevents this sender from sending this message to this recipient; type=\"method_call\", sender=\":1.72\" (uid=1000 pid=1795 comm=\"/snap/strawberry/x1/usr/bin/strawberry \" label=\"snap.strawberry.strawberry (enforce)\") interface=\"org.freedesktop.DBus.ObjectManager\" member=\"GetManagedObjects\" error name=\"(unset)\" requested_reply=\"0\" destination=\"org.freedesktop.UDisks2\" (uid=0 pid=592 comm=\"/usr/lib/udisks2/udisksd \" label=\"unconfined\")"

Snap of Strawberry Music Player

It seems your snap is trying to detect if it is on the network. Would the new ‘network-manager-observe’ interface work for you? If not, since network-manager grants access to configure all networking on the device, why does a music player need to configure networking?

This isn’t surprising for a music player, but I wonder since strawberry is just a player why pulseaudio wouldn’t be better. Can you comment?

Typically one uses the ‘removeable-media’ interface for this sort of thing rather than udisks2 directly. Indeed, it is surprising that a music player requires the ability to configure and partition disks for the entire system, which is what udisks2 provides (and therefore device ownership of the device). Can you comment on why ‘removeable-media’ is insufficient for your use case?


You are right about network-manager, network-manager-observe is sufficient. I’ve changed to network-manager-observe in snapcraft.yaml now.

A lot of users prefer not to use pulseaudio, some uninstall it from their system. I’ve been using Linux on the desktop since before pulseaudio came default in distros and still never use pulseaudio and do not even have it installed on the system.
I know direct output to alsa is relevant to a lot of users because of the amount of e-mails and feedback I receive from users.
The problem with the snap is that new users who wants to try it thinks the player is broken because they can’t select their sound card in the settings, and they blame the player because they do not know about the restrictions in the snap.
I realize pulseaudio has it’s uses, if you have multiple soundscards, headphones and want an easy way to direct the sound output from applications where you can’t select output. But for me and a lot of other users we set up a computer in the living room connected to the TV with a DAC that is mostly used for music, we want the sound to go directly to the DAC without any resampling or the use of pulseaudio.

It’s for the udisk2 device lister, it still fails if just connecting “removable-media”.
It uses OrgFreedesktopDBusObjectManagerInterface::GetManagedObjects
The code that fails is here:

It needs the removable-media too, otherwise users won’t be able to add music from removable devices, I already have it in the snapcraft.yaml file but thought it was auto-connected.

So to summarize it needs:

  • network-manager-observe
  • alsa
  • udisks2
  • removable-media


+1 for network-manager-observe, alsa and removeable-media (though I recommend that your application also supports pulseaudio because not all hardware can do multiplexing through alsa directly)

-1 for auto-connects udisks2. I understand that your application wants to list devices, however the udisks2 interface is far too much access to grant by default. I suggest adjusting your application to either not require udisks or to detect that the access is not available and somehow let the user know that the manual connection must be made.

@reviewers - can others vote?


I am also +1 on network-manager-observe, alsa and removable-media, and would strongly encourage using pulseaudio instead of alsa, if possible.

I’m -1 also for udisks2 for the reasons specified by @jdstrand.


I concur:

  • +1 on network-manager-observe, alsa and removeable-media
  • -1 on udisks2 as the interface currently stands - can the application simply enumerate devices under /media/$USER instead?


3 votes for, 0 against for network-manager-observe, alsa and removeable-media
0 votes for, 3 against for udisks2

Granting auto-connection for network-manager-observe, alsa and removeable-media. This is now live.