[Desktop-packages] [Bug 1884299] Re: Chromium snap won't run with nfs home drive
Matthieu, more recently a more likely problem has been characterized by Alberto Mardegan and found the line in question in https://bugs.launchpad.net/snapd/+bug/1973321 In particular, restarting snapd doesn't help at all for me, so having the directory mounted before snapd starts doesn't help, and the same problem occurs with other file systems. However _starting_ outside the home directory does help. This is the situation for me with Kerberos authenticated NFS, and others with sshfs. I don't know whether it is relevant for people using NFS without authentication. It is easy to test for yourself - restart snapd and see if that helps. So I think there is progress in understanding the problem, even if not working out how to fix it. FYI: I initially tried a work around where I used the debian repository for firefox instead of the snap version, but despite giving it a higher priority (confirmed via "sudo apt policy firefox") I found the debian package twice over a week uninstalled and replaced by the snap version that then would not start. I can manually revert it but it is inconvenient. Any suggestions on how to make that work reliably would be appreciated. -- 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/1884299 Title: Chromium snap won't run with nfs home drive Status in firefox package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Confirmed Bug description: My physical computer lab uses AutoFS home drives (per https://help.ubuntu.com/community/Autofs#Wildcard_characters). If any user tries to run chromium browser, it fails. I assume it is related to these: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552 But that says a fix was released, but seems toi only work for NFS home drives https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1782873 That ones is reported as a dupe but it's not, AutoFS home drives still don't work. $ chromium -v cannot create user data directory: /home/test.student2/snap/chromium/1193: Stale file handle $ tail -f /var/log/syslog Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188657] nfs: RPC call returned error 13 Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188666] nfs: RPC call returned error 13 Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188695] audit: type=1400 audit(1592590869.460:59): apparmor="DENIED" operation="sendmsg" profile="/snap/snapd/8140/usr/lib/snapd/snap-confine" pid=12884 comm="snap-confine" laddr=192.168.43.216 lport=766 faddr=192.168.43.4 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188697] audit: type=1400 audit(1592590869.460:60): apparmor="DENIED" operation="sendmsg" profile="/snap/snapd/8140/usr/lib/snapd/snap-confine" pid=12884 comm="snap-confine" laddr=192.168.43.216 lport=766 faddr=192.168.43.4 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" $ lsb_release -rd Description: Ubuntu 20.04 LTS $ apt policy chromium-browser chromium-browser: Installed: 81.0.4044.129-0ubuntu0.20.04.1 Candidate: 81.0.4044.129-0ubuntu0.20.04.1 Version table: *** 81.0.4044.129-0ubuntu0.20.04.1 500 500 http://ca.archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages 100 /var/lib/dpkg/status 80.0.3987.163-0ubuntu1 500 500 http://ca.archive.ubuntu.com/ubuntu focal/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1884299/+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
[Desktop-packages] [Bug 1784774] Re: snapd is not autofs aware and fails with nfs home dir
Thanks Alberto. I tried running "hello" in a different directory, and you were correct: arc@andrewfairfield:~$ hello cannot open path of the current working directory: Permission denied arc@andrewfairfield:~$ cd / arc@andrewfairfield:/$ hello Hello, world! arc@andrewfairfield:/$ [ This is in 20.04, not 22.04 ] Yay! that is the first time I have seen a snap actually work with my normal user account. This feels like significant progress in working out what is going on! Of course firefox needs access to the home directory to load the profile and store downloads. Is the whole process run as some other user (a la sudo) or is there just some starting stub running as some other user doing something that returns to the actual user after doing something that thinks it needs access to the current directory but could get by without it? Actually, I can sort of answer that - I tried running "musescore" as a snap, starting from / It successfully ran. I tried saving something, and it sort of did... but in a new, empty "home" directory in a /home/arc/snap/musescore/216/ that the save file dialog went to when I pressed the home button. Is this normal behaviour for a snap? Regardless of the inconvenience of the subdirectory, that is running over nfs successfully. I can close Musescore and load it again. But not with cwd=/home/arc. So that is fairly strong evidence supporting your idea that it is the same root cause as https://bugs.launchpad.net/bugs/1973321 . I will add a comment there. Thanks for the insight Alberto! -- 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
[Desktop-packages] [Bug 1884299] Re: Chromium snap won't run with nfs home drive
I (using Kerberos) don't the get apparmor DENIED messages that Eric (not using Kerberos) did, but I get exactly the same "cannot open path of the current working directory: Permission denied" error. -- 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/1884299 Title: Chromium snap won't run with nfs home drive Status in firefox package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Confirmed Bug description: My physical computer lab uses AutoFS home drives (per https://help.ubuntu.com/community/Autofs#Wildcard_characters). If any user tries to run chromium browser, it fails. I assume it is related to these: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552 But that says a fix was released, but seems toi only work for NFS home drives https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1782873 That ones is reported as a dupe but it's not, AutoFS home drives still don't work. $ chromium -v cannot create user data directory: /home/test.student2/snap/chromium/1193: Stale file handle $ tail -f /var/log/syslog Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188657] nfs: RPC call returned error 13 Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188666] nfs: RPC call returned error 13 Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188695] audit: type=1400 audit(1592590869.460:59): apparmor="DENIED" operation="sendmsg" profile="/snap/snapd/8140/usr/lib/snapd/snap-confine" pid=12884 comm="snap-confine" laddr=192.168.43.216 lport=766 faddr=192.168.43.4 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188697] audit: type=1400 audit(1592590869.460:60): apparmor="DENIED" operation="sendmsg" profile="/snap/snapd/8140/usr/lib/snapd/snap-confine" pid=12884 comm="snap-confine" laddr=192.168.43.216 lport=766 faddr=192.168.43.4 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" $ lsb_release -rd Description: Ubuntu 20.04 LTS $ apt policy chromium-browser chromium-browser: Installed: 81.0.4044.129-0ubuntu0.20.04.1 Candidate: 81.0.4044.129-0ubuntu0.20.04.1 Version table: *** 81.0.4044.129-0ubuntu0.20.04.1 500 500 http://ca.archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages 100 /var/lib/dpkg/status 80.0.3987.163-0ubuntu1 500 500 http://ca.archive.ubuntu.com/ubuntu focal/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1884299/+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
[Desktop-packages] [Bug 1784774] Re: snapd is not autofs aware and fails with nfs home dir
Using NVFv4, kerberos authenticated, mounted by autofs: arc@andrewshoreham:~$ hello cannot open path of the current working directory: Permission denied [ Then as user with sudo privs, sudo systemctl restart snapd ] arc@andrewshoreham:~$ hello cannot open path of the current working directory: Permission denied Logs since just before restarting snapd syslog -- May 15 14:54:09 andrewshoreham kernel: [12319.195323] audit: type=1400 audit(1652590449.676:183): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/24886/cmdline" pid=910 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 May 15 14:54:09 andrewshoreham systemd[1]: Stopping Snap Daemon... May 15 14:54:09 andrewshoreham snapd[726]: main.go:155: Exiting on terminated signal. May 15 14:54:09 andrewshoreham snapd[726]: overlord.go:504: Released state lock file May 15 14:54:09 andrewshoreham systemd[1]: snapd.service: Deactivated successfully. May 15 14:54:09 andrewshoreham systemd[1]: Stopped Snap Daemon. May 15 14:54:09 andrewshoreham systemd[1]: snapd.service: Consumed 2.753s CPU time. May 15 14:54:09 andrewshoreham systemd[1]: Starting Snap Daemon... May 15 14:54:09 andrewshoreham snapd[24890]: AppArmor status: apparmor is enabled and all features are available May 15 14:54:09 andrewshoreham snapd[24890]: overlord.go:263: Acquiring state lock file May 15 14:54:09 andrewshoreham snapd[24890]: overlord.go:268: Acquired state lock file May 15 14:54:09 andrewshoreham snapd[24890]: daemon.go:247: started snapd/2.55.3+22.04 (series 16; classic) ubuntu/22.04 (amd64) linux/5.15.0-25-generic. May 15 14:54:09 andrewshoreham kernel: [12319.270748] loop11: detected capacity change from 0 to 8 May 15 14:54:09 andrewshoreham snapd[24890]: daemon.go:340: adjusting startup timeout by 1m10s (pessimistic estimate of 30s plus 5s per snap) May 15 14:54:09 andrewshoreham systemd[1]: tmp-sanity\x2dmountpoint\x2d2760788470.mount: Deactivated successfully. May 15 14:54:09 andrewshoreham snapd[24890]: backend.go:133: snapd enabled NFS support, additional implicit network permissions granted May 15 14:54:10 andrewshoreham kernel: [12319.549118] audit: type=1400 audit(1652590450.028:184): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/snapd/snap-confine" pid=24926 comm="apparmor_parser" May 15 14:54:10 andrewshoreham kernel: [12319.578896] audit: type=1400 audit(1652590450.060:185): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=24926 comm="apparmor_parser" May 15 14:54:10 andrewshoreham kernel: [12319.969313] audit: type=1400 audit(1652590450.448:186): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/snap/snapd/15534/usr/lib/snapd/snap-confine" pid=24946 comm="apparmor_parser" May 15 14:54:10 andrewshoreham kernel: [12319.983029] audit: type=1400 audit(1652590450.464:187): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/snap/snapd/15534/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=24946 comm="apparmor_parser" May 15 14:54:10 andrewshoreham kernel: [12320.165228] audit: type=1400 audit(1652590450.644:188): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.snapd-desktop-integration.hook.configure" pid=24950 comm="apparmor_parser" May 15 14:54:10 andrewshoreham kernel: [12320.341043] audit: type=1400 audit(1652590450.820:189): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.snapd-desktop-integration.snapd-desktop-integration" pid=24951 comm="apparmor_parser" May 15 14:54:11 andrewshoreham kernel: [12320.633250] audit: type=1400 audit(1652590451.112:190): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.snap-store" pid=24948 comm="apparmor_parser" May 15 14:54:11 andrewshoreham kernel: [12320.721431] audit: type=1400 audit(1652590451.200:191): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.snapd-desktop-integration" pid=24949 comm="apparmor_parser" May 15 14:54:11 andrewshoreham kernel: [12320.727129] audit: type=1400 audit(1652590451.208:192): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.hello" pid=24954 comm="apparmor_parser" May 15 14:54:11 andrewshoreham systemd[1]: Started Snap Daemon. May 15 14:54:11 andrewshoreham dbus-daemon[693]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.166' (uid=0 pid=24890 comm="/usr/lib/snapd/snapd " label="unconfined") May 15 14:54:11 andrewshoreham systemd[1]: Starting Time & Date Service... May 15 14:54:11 andrewshoreham dbus-daemon[693]: [system] Successfully
[Desktop-packages] [Bug 1784774] Re: snapd is not autofs aware and fails with nfs home dir
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
[Desktop-packages] [Bug 1884299] Re: Chromium snap won't run with nfs home drive
Firefox also doesn't work now it is a snap in 22.04. I think there are still multiple issues here. The original poster seems to be using NVSv3 I believe based on the RPC errors (NFSv3 uses multiple ports, one of which is called something like RPC, but I am not an expert in this as I have only used NFSv4, which uses a single port). Is this correct tylerecouture? NFSv3 has no user authentication; NFSv4 uses Kerberos for authentication (and privacy and tamper resistance). I think this brings in additional problems as snaps don't appear to work with Kerberos e.g. https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1849346 https://bugzilla.mozilla.org/show_bug.cgi?id=1734791 I get a very different error - a simple permission denied error rather than an AppArmor problem. ** Bug watch added: Mozilla Bugzilla #1734791 https://bugzilla.mozilla.org/show_bug.cgi?id=1734791 ** Also affects: firefox (Ubuntu) Importance: Undecided Status: New -- 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/1884299 Title: Chromium snap won't run with nfs home drive Status in firefox package in Ubuntu: New Status in snapd package in Ubuntu: Confirmed Bug description: My physical computer lab uses AutoFS home drives (per https://help.ubuntu.com/community/Autofs#Wildcard_characters). If any user tries to run chromium browser, it fails. I assume it is related to these: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552 But that says a fix was released, but seems toi only work for NFS home drives https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1782873 That ones is reported as a dupe but it's not, AutoFS home drives still don't work. $ chromium -v cannot create user data directory: /home/test.student2/snap/chromium/1193: Stale file handle $ tail -f /var/log/syslog Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188657] nfs: RPC call returned error 13 Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188666] nfs: RPC call returned error 13 Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188695] audit: type=1400 audit(1592590869.460:59): apparmor="DENIED" operation="sendmsg" profile="/snap/snapd/8140/usr/lib/snapd/snap-confine" pid=12884 comm="snap-confine" laddr=192.168.43.216 lport=766 faddr=192.168.43.4 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jun 19 11:21:09 tbl-h10-4 kernel: [18949.188697] audit: type=1400 audit(1592590869.460:60): apparmor="DENIED" operation="sendmsg" profile="/snap/snapd/8140/usr/lib/snapd/snap-confine" pid=12884 comm="snap-confine" laddr=192.168.43.216 lport=766 faddr=192.168.43.4 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" $ lsb_release -rd Description: Ubuntu 20.04 LTS $ apt policy chromium-browser chromium-browser: Installed: 81.0.4044.129-0ubuntu0.20.04.1 Candidate: 81.0.4044.129-0ubuntu0.20.04.1 Version table: *** 81.0.4044.129-0ubuntu0.20.04.1 500 500 http://ca.archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages 100 /var/lib/dpkg/status 80.0.3987.163-0ubuntu1 500 500 http://ca.archive.ubuntu.com/ubuntu focal/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1884299/+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
[Desktop-packages] [Bug 1784774] Re: snapd is not autofs aware and fails with nfs home dir
I did some more investigating, and I think there are two independent problems here: (1) The problem as believed so far, network access permissions (2) New insight: Kerberos doesn't work with snaps. This explains why fixing (1) didn't help me (or Adam). Background: Kerberos is the authentication mechanism used for NFS. Assuming you are using authentication (as almost everyone does), then when you access NFS contents, you need to provide kerberos credentials. These are stored outside of your home directory (after all, home directories are one of the most common reasons to use NFS, so you can't store them there). I believe snaps restrict access to just your home directory, so you can't access the Kerberos key and therefore can't access your home directory. This is supported by various bugs like https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1849346 (unresolved) which is a different but relevant issue - people who don't use NFS but do use Kerberos features in Firefox found they don't work post snap conversion. -- 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
[Desktop-packages] [Bug 1784774] Re: snapd is not autofs aware and fails with nfs home dir
I never got it to work in 20.04, so I don't know whether your fix ever made it in. I have just installed Jammy Jellyfish (22.04), and can confirm snaps don't work in it when using autofs and nfs mounted home directories. The prior work around was just never use any snap applications, which was OK as nothing important was in snaps prior to 22.04. This is harder in 22.04 as firefox is distributed as a snap, and so firefox doesn't work in 22.04 if you have autofs NFS home directories. Work around is to use a different source for firefox, https://ubuntuhandbook.org/index.php/2022/04/install-firefox-deb- ubuntu-22-04/ but I don't know whether that will get security updates as quickly, so this is a serious problem. ** Also affects: firefox (Ubuntu) Importance: Undecided Status: New -- 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
