snapd is not autofs aware and fails with nfs home dir

Bug #1784774 reported by Andrew Conway on 2018-08-01
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Zygmunt Krynicki
snapd (Ubuntu)

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). ]

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in snapd (Ubuntu):
status: New → Confirmed
Santiago Castro (bryant1410) wrote :

I created a patch to workaround this problem: It's basically hardcoding a value. I'm not sure what the correct behavior should be for all the cases that /home is autofs, or if it should check that /home/user is NFS instead.

So, as a workaround, you can clone the repo, checkout that commit, build from source as stated in the repo, place the snapd executable in /usr/local/bin and edit the systemctl service file (/lib/systemd/system/snapd.service) to point to that executable instead.

Santiago Castro (bryant1410) wrote :

With snap and snapd 2.35.2, it seems to be working for me now.

This is still broken on bionic, AutoFS mounted home directories are not detected

John Lenton (chipaca) wrote :

snapd will not work properly with users' homes that are unavailable if the user is not logged in. As a workaround, schedule refreshes to only happen when all the local users are logged in.

The issue is NFS detection only happens at snapd start, and on boot no NFS shares are mounted yet.

If an AutoFS NFS user logs in, and then snapd is restarted, NFS support is enabled

Zygmunt Krynicki (zyga) on 2019-03-21
Changed in snapd (Ubuntu):
assignee: nobody → Zygmunt Krynicki (zyga)
assignee: Zygmunt Krynicki (zyga) → nobody
Changed in snapd:
assignee: nobody → Zygmunt Krynicki (zyga)
status: New → Triaged
importance: Undecided → Medium
Andrew Conway (acubuntuone) wrote :

I just tested restartung snapd while I am logged in via kerberos with an autofs home directlry. It doesn't seem to help. In particular, I tried launching system monitor (which uses snap) unsuccessfully. Using 18.04 with kerberos, and /home/<my-user-name> mounted via autofs.

Checking that /home is autofs will not solve the problem, if /home/user is autofs, which is useful in the case of having a local user that has a home directory in the standard place.

Philippe Clérié (pclerie) wrote :

I'd like to confirm Andrew Conway's report. Restarting snapd does not change anything.

Could you at least up the priority of the bug. After all it's been there for quite a while, it's been confirmed and people have worked and are working on it. Just a little push to solve it. Pretty please! :-)

Zygmunt Krynicki (zyga) wrote :

I'm sorry for not fixing this yet. A few higher priority bugs kept me busy lately. I will look at fixing it next Monday, with a bit of hope it may be easy and I can get it done without shuffling other planned work.

Marc Kolly (makuser) wrote :

@zyga any update on this?

Zygmunt Krynicki (zyga) wrote :

With the additional information in I think we can fix this issue quickly.

1) The mountinfo parser will now look for an automount point that mentions autofs, an example line is mentioned here:

137 29 0:50 / /home rw,relatime shared:87 - autofs /etc/auto.master.d/home rw,fd=7,pgrp=22588,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=173399

2) We could optionally look at the referenced file (/etc/auto.master.d/home) and parse it, in this case it contains this line (among others)

* -fstype=nfs,vers=4,rw,soft,rsize=8192,wsize=8192

With this information we can enable the workaround reliably.

I will not do 2) at first, unless reviewers deem it necessary.

Zygmunt Krynicki (zyga) wrote :
Changed in snapd:
status: Triaged → In Progress
milestone: none → 2.46
Zygmunt Krynicki (zyga) on 2020-06-29
Changed in snapd:
status: In Progress → Fix Committed
Andrew Conway (acubuntuone) wrote :

Thanks for fixing this! Much appreciated.

I tried to check that it worked, but possibly it has not gotten into updates yet. How would I check?

[ running snap-store from the command line in home dir causes the error "cannot open path of the current working directory: Permission denied". Running from the GUI has no effect. ]

While I am here, this is probably unrelated, but a couple of days after the above commit, nfs home directories on the current kernel caused the machine to freeze shortly after logging in. I have put a link to that report below on the off chance you can think of a reason that this change could cause it.


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers