No SSSD support in snaps (nsswitch.conf)


Given: A host that does user auth with SSSD (“LDAP”).
With base: core18 (or maybe in general?) /etc/nsswitch.conf is bound to something different than the host’s nsswitch.conf


# snap
passwd:         compat extrausers


# host
passwd:         compat  systemd sss

Thus, within the snap context, getent passwd $USER will not succeed for non-local users.

Is that a supported use-case and should this work? Because if not, snapcraft-desktop-helpers and its “successor” the gnome extension ( can never successfully link remote users’ home directories into the snap. Quite problematic indeed for desktop applications.

Any suggestions or ideas on how to tackle this problem?

The docs roadmap

I’m not sure I understand the problem. In what cases does snapcraft-desktop-helpers etc “link remote users’ home directories into the snap”?


Bad choice of words. desktop-launch softlinks xdg dirs for convenient access. I’m referring to which gets its $REALHOME from here

REALHOME cannot be deduced for users from sssd and is thus empty. You’ll find xdg dirs in your file chooser dialogs that do not correspond to those in the user’s home directory.


This old topic describes the root problem very well and presents a nice and easy test for user resolution failing for devices using SSSD.

An “okay” workaround in regards to the wrapper script is to deduce the “obvious” home dir from $SNAP_USER_DATA if getent does not return anything useful.

Snapcraft build, debug and publishing docs roadmap

have you looked at



@chipaca Absolutely phenomenal. That is indeed a good solution and works beautifully. Thank you very much. I had overlooked this topic as my search was not generic enough after a long day :exploding_head:

For reference: Installing and running nscd or unscd on the host enables SSSD (and more) user resolution within the snap.

I’m wondering whether that could be a good addition somewhere in the docs…


paging @degville to answer that one, as I don’t hold the docs in my head as well as he does.


Good question - I think in the near future, this solution will be better referenced from the new Snapcraft build, debug and publishing docs roadmap, which we are working on and will complete soon. There’s troubleshooting for each phase and this will be a common question.

But it’s probably also worth mentioning in some of our environment variable documentation, where you might expect references to a user’s $HOME, for example.

I’ll make a note to do both of the above.


It is probably of equal or greater interest to users rather than developers: a snap might work without issue on the developer’s machine, but fails for a user on a machine configured to use LDAP.

It’s not really something the snap author can handle from their side of the sandbox.


Yes, that is strictly a user thing. In a perfect world, the user would be informed upon installation or running of a snap that the current user cannot be resolved and a solution would be proposed.