I got exactly the same errors as Miles above; a simple permission denied error stopping things before AppArmor got involved.
I.e., the answer to Markus Kuhn's question is no, in fact even in enforce mode there are no denied apparmor complaints. I don't know whether this is because the gating problem is not being able to read the ticket in /tmp, or whether being in the kernel solves some of the apparmor issues, but the greater pickiness of kerberos user definition is an issue. Do snaps run as a different uid? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1784774 Title: snapd is not autofs aware and fails with nfs home dir Status in snapd: Fix Released Status in firefox package in Ubuntu: New Status in snapd package in Ubuntu: Fix Released Bug description: This is similar to bugs 1662552 and 1782873. In 1782873, jdstrand asked me to open a new bug for this specific issue. In 1662552, snapd fails for nfs mounted home directories as network permissions are not enabled. A work around was implemented that works if the mount is done via a /home mount at boot. However this does not work if people mount home directories via autofs. This is probably the fundamental problem for 1782873 although there may be other issues. [ Why use autofs? If some but not all of users want to use nfs homes. In particular, I have a local user on all my accounts that does not require the nfs server to be up or the kerberos server to be up, or kerberos working on the client machines, etc. It is very useful when something goes wrong. It means I mount /home/user rather than /home (for several users). ] To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1784774/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
