Yes, we are using Autofs. thisisme@jammy:~$ cat /etc/auto.staff * -rw,nosuid nfshome.domain.edu:/nfshome/staff/&
thisisme@jammy:~$ cat /etc/auto.master /fac auto.fac --timeout=120 /staff auto.staff --timeout=120 thisisme@jammy:~$ pwd /staff/thisisme thisisme@jammy:~$ mount|grep staff nfshome.domain.edu:/nfshome/staff/thisisme on /staff/thisisme type nfs4 (rw,nosuid,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=XX.YY.ZZ.66,local_lock=none,addr=XX.YY.ZZ.16) thisisme@jammy:~$ snap list Name Version Rev Tracking Publisher Notes bare 1.0 5 latest/stable canonical✓ base chromium 101.0.4951.64 1993 latest/stable canonical✓ - core20 20220329 1434 latest/stable canonical✓ base gnome-3-38-2004 0+git.1f9014a 99 latest/stable canonical✓ - gtk-common-themes 0.1-59-g7bca6ae 1519 latest/stable canonical✓ - snapd 2.55.3 15534 latest/stable canonical✓ snapd thisisme@jammy:~$ chromium-browser cannot open path of the current working directory: Permission denied root@jammy:~# journalctl -f May 13 08:58:31 jammy snapd[128770]: main.go:155: Exiting on terminated signal. May 13 08:58:31 jammy snapd[128770]: overlord.go:504: Released state lock file May 13 08:58:31 jammy systemd[1]: Stopping Snap Daemon... May 13 08:58:31 jammy systemd[1]: snapd.service: Deactivated successfully. May 13 08:58:31 jammy systemd[1]: Stopped Snap Daemon. May 13 08:58:31 jammy systemd[1]: Starting Snap Daemon... May 13 08:58:31 jammy snapd[128952]: AppArmor status: apparmor is enabled and all features are available May 13 08:58:31 jammy snapd[128952]: overlord.go:263: Acquiring state lock file May 13 08:58:31 jammy snapd[128952]: overlord.go:268: Acquired state lock file May 13 08:58:31 jammy snapd[128952]: daemon.go:247: started snapd/2.55.3+22.04ubuntu1 (series 16; classic) ubuntu/22.04 (amd64) linux/5.15.0-30-generic. May 13 08:58:31 jammy kernel: loop6: detected capacity change from 0 to 8 May 13 08:58:31 jammy systemd[1]: tmp-sanity\x2dmountpoint\x2d2266021507.mount: Deactivated successfully. May 13 08:58:31 jammy snapd[128952]: daemon.go:340: adjusting startup timeout by 1m0s (pessimistic estimate of 30s plus 5s per snap) May 13 08:58:31 jammy systemd[1]: Started Snap Daemon. May 13 08:58:31 jammy dbus-daemon[495]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.3815' (uid=0 pid=128952 comm="/usr/lib/snapd/snapd " label="unconfined") May 13 08:58:31 jammy systemd[1]: Starting Time & Date Service... May 13 08:58:31 jammy dbus-daemon[495]: [system] Successfully activated service 'org.freedesktop.timedate1' May 13 08:58:31 jammy systemd[1]: Started Time & Date Service. May 13 08:58:34 jammy systemd[127902]: Started snap.chromium.chromium.7948c287-207b-4d96-b9af-02061a62addc.scope. May 13 08:58:34 jammy audit[128990]: AVC apparmor="DENIED" operation="sendmsg" profile="/usr/lib/snapd/snap-confine" pid=128990 comm="snap-confine" laddr=XX.YY.ZZ.66 lport=680 faddr=XX.YY.ZZ.16 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" May 13 08:58:34 jammy kernel: nfs: RPC call returned error 13 May 13 08:58:34 jammy kernel: audit: type=1400 audit(1652450314.955:85): apparmor="DENIED" operation="sendmsg" profile="/usr/lib/snapd/snap-confine" pid=128990 comm="snap-confine" laddr=XX.YY.ZZ.66 lport=680 faddr=XX.YY.ZZ.16 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" -- 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: Confirmed Status in snapd package in Ubuntu: Incomplete 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
