Hello, I recently had a machine running Ubuntu auto-update its snap to version 1.1. In this version, there seems to be a new mechanism to determine the default config path using getent that is not functional on my system. Some particularities that I have: 1) passwd / groups of users come from a Samba AD using sssd 2) home directories are mounted on NFS The problem that I see is that the REALHOME variable is not set correctly, so it tries to look for the configuration in /.config/inkscape. This is what I see when launching: ==== $ LANGUAGE=en_CA:en inkscape /bin/bash: /home/doug/.bashrc: Permission denied /bin/bash: /home/doug/.bashrc: Permission denied /bin/bash: /home/doug/.bashrc: Permission denied Unable to init server: Could not connect: Connection refused ** Message: 08:43:39.229: Cannot create profile directory /.config/inkscape. ** Message: 08:43:39.229: Inkscape will run with default settings, and new settings will not be saved. ** (inkscape:3501254): WARNING **: 08:43:39.395: Could not create directory '/.config/inkscape' ** (inkscape:3501254): WARNING **: 08:43:39.396: Could not create extension error log file '/.config/inkscape/extension-errors.log' ** (inkscape:3501254): WARNING **: 08:43:39.476: Fonts dir '/.config/inkscape/fonts' does not exist and will be ignored. ==== So, the first thing I tried is to add the following in the snap's apparmor profile: #include <abstractions/nameservice> #include <abstractions/bash> And this got rid of the bashrc access errors (which likely aren't fatal, anyway), and I could get a proper result with this: aa-exec -p snap.inkscape.inkscape getent passwd $UID So, I thought this would work. However, it still doesn't... With careful use of ctrl-Z and attaching strace (since it seems you can't strace directly), I was able to see that the /etc/nsswitch.conf being used by inkscape is coming from inside a chroot or otherwise remapped by snap, and it does not use the system /etc/nsswitch.conf. It looks exactly like this issue: https://forum.snapcraft.io/t/no-sssd-support-in-snaps-nsswitch-conf/10412/12 It seems like the only way around this problem is to use NSCD as a proxy, which is generally not recommended, it seems, but might be the only choice I would have. (Using unscd does seem to work, even with 0 cache ttls -- so I think this should be safe) All this to say -- would it be possible to have a fallback in the environment to use the old behaviour (was it to use $HOME as REALHOME?) in case the calls to getent fail? Or, at the least, it should be documented that using nscd/unscd is required when a different nsswitch.conf configuration is used. Thanks, -- Douglas Paul