Home directories outside of ‘/home’ on NFS Share

Hi All

Operating System: Ubuntu 22.04.4 LTS Kernel: Linux 6.5.0-28-generic Architecture: x86-64

Our current users home directories on are a NFS share and the user logs in using Windows LDAP (sssd) . I have tried a few things but get permission denied when running Firefox

mount --rbind /home /tmp/snap.rootfs_8R8mhK//home: Permission denied

/home points to the following NFS share /rmd/tlg/home/ using a symbolic link (ln -s)

I have tried the following

sudo dpkg-reconfigure apparmor “/rmd/tlg/home/ /home” and also creating a alt-homedir

sudo snap set homedirs=/rmd/tlg/home/ Doesnt work either

Someone mentioned changing the sssd.conf and seeing if this makes a difference

Any ideas how we get snap to work?


1 Like

I do not have the environment to reproduce this, but

shouldn’t it be sudo snap set system homedirs=/rmd/tlg/home/ ?


1 Like

Even without the typo , it still doesnt work

The only action at the moment is to remove the snap store completely and install Firewall from Moz.

Not ideal but gets the user working.

Not sure how similar what I’m doing is to yours, but I’m trying something like that, except I don’t my NFS home to be the home, where the config files might get mucked up. I just want it to share files.

is it possible to set multiple homedirs?

[NOTE: Frustration expressed. If Snap devs have solved these problems, hooray, you should still have to read how you made thousands or more people feel in the meantime for not doing the obvious]

This has been an underlying problem in the Snap mindset for years now, going against Unix and Linux standard practice the entire time. Snap staff does not appear to understand what happens in large-scale environments, and instead is restricting it to the small. To Wit:

  • Home directories can be ANYWHERE, not just in the non-standard /home
  • There are potentionally hundreds of mount points that can contain home directories
  • The mount points cannot be predicted to the level just above $HOME in automounts
  • It is essential to be able to trust multiple levels down from a given base directory

Example: Many sites have automount maps that allow home directories resident on users’ workstation to be visible site wide through automounting. The (LDAP) password entries have home directories similar to /nfs/somehostnick/some/path/name/username - and this is just a simple case, I’m not even going to go into the Andrew File System and its worldwide pathnames, where again, home directories can look entirely arbitrary other than that base directory referring to some service. Also, these sites have been around forever (in some cases) and can’t change themselves to fit some developer’s pet mission to “secure” home paths by scaling them down to his/her personal perception of what constitutes reasonable.

So, now people are going to jump in and so, “Oh, just make /home and automap for everyone’s home directories instead of them been scattered everywhere!” - which makes sense, except that it rarely works well above a few thousand users, because there’s a lot of lag around fetching inode information (ACROSS THE PLANET FOR AFS!) or from hosts that are down, or when some reasonable person has decided to run a script to iterate through all known homes to look at dotfiles or something. It takes multiple minutes to make a long listing of /home/ at many sites trying to make the /home “standard” (which it isn’t) work.

So for anything thinking the Snap home directory model as it stands (dare I hope for “stood”?), will EVER work in the real world, you are wrong, developers included.

Snap home directory trust needs to have ways to do the following:

  • Trust anything claimed to be a home directory through password entry (including LDAP)
  • Trust anything under an abitrary prefix (like the /nfs and /afs random examples)
  • Trust anything at all, if the admins want to set the above prefix to “/”
  • If a trusted path uses symlinks, or odd mounts, Snap needs to trust the directory reached

If snap fails to support these cases, then snap has failed, period. And I say this as I go to either dpkg versions of Thunderbird and Firefox, or just compile them myself again, because this braindamage just doesn’t seem to go away.


Damn. Wish that gets fixed with a flag or something…

You have summed this up in one go. Snap needs to work on NFS share/LDAP etc. One work around is to create a local users, and then from the terminal su user firefox …

Not really ideal for 100’ of users