Over on Twitter, I said something about Firefox in 22.04:

So Ubuntu 22.04 (beta) makes Firefox into a Snap. I guess our users won't be using it on our machines any more, since Snaps don't work at all in our environment. (Or they didn't in 20.04; they require non-NFS home directories in /home.)

After I made that Tweet I did some experimentation on 22.04 and so I can now say positively that Canonical Snaps don't work in our environment, where we use NFS v3 mounted home directories from our ZFS fileservers. Well, probably and mostly. Snaps definitely don't work out of the box on Ubuntu 22.04, and I'm not convinced it's possible to fix all of their problems with manual work.

One major problem is that the AppArmor profiles used to "restrict" snaps make specific assumptions about the system environment in at least two areas. The first area and the easiest to modify is where people's home directories are. The standard Ubuntu AppArmor configuration more or less assumes everyone's home directory is directly in /home as /home/<user>. However, this can (theoretically) be tuned through modifying /etc/apparmor.d/tunables/home.d/site.local; for us, I think we would do something like:

@{HOMEDIRS}+=/h/*/

(Our NFS mounted home directories all have names like /h/281, and then users have home directories like /h/281/cks.)

Unfortunately this is only the start of the problems. As covered in places like Bug #1662552 "snaps don't work with NFS home", the AppArmor profiles generally don't allow 'networking', and this affects kernel networking for NFS. This has apparently been somewhat worked around in modern versions of Snaps, according to sources like Cannot open path of the current working directory: Permission denied bis.

(The workaround seems to be to automatically give all Snaps network access. This obviously reduces the security protections for some Snaps, although not Firefox since Firefox already needs to talk to the network.)

However, this leaves another major issue, also discussed in the Cannot open path report; various Snap internal operations run as root and require access to user home directories, which requires your NFS server to allow root on NFS clients unrestricted access (for both reads and writes). This is a non-starter in our environment, where we're quite guarded about allowing root casual, unrestricted access to the entire NFS filesystems.

(We are of course perfectly aware that someone with root access on a NFS client can read and possibly write any file on an NFS mount, because they can assume the appropriate UID. However, this is vastly different from a situation where any accident as root allows an errant script, program, or command to wipe out vast amounts of data on our fileservers. Unfortunately, per exports(5) you can't give a client un-squashed root only for reads; if you allow read/write access to the filesystem and don't squash root, root gets write as well as read.)

PS: It's possible that there are also issues because our NFS clients normally have an /etc/passwd that lists people's home directories as '/u/<user>', where /u is a directory full of symbolic links to the real locations. We're not interested in changing this aspect of our systems either.