Ubuntu
autofs package

Automount NFSv4 doesn't work

Bug #1418279 reported by Jens Elkner
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
autofs (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

I'm trying to use NFSv4 automount within an lxc container, however, it doesn't work (it works for Solaris zones, so that's not an server issue).

> cd /net/pkg/<TAB>
/net/pkg/ not found

> cat /etc/auto.master
/net -hosts
+dir:/etc/auto.master.d
+auto.master

The following log message makes me suspicious (comes 3-4 times):
[Feb 5 01:51] audit: type=1400 audit(1423099036.365:94): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-container-default" name="/tmp/autoHBYlmU/" pid=27748 comm="mount" srcname="/tmp/autogYuIlN/" flags="rw, bind"

But AFAICS rw,bind is allowed:
>cat /etc/apparmor.d/lxc/lxc-default
profile lxc-container-default flags=(attach_disconnected,mediate_deleted) {
  deny mount fstype=devpts,
 mount options=(rw, rbind),
 mount fstype=nfs,
 mount fstype=nfs4,
 mount fstype=rpc_pipefs,
 mount fstype=autofs,
}
That's the profile in the global/parent zone used by all our containers. So not sure, whether it is actually a NFSv4 or apparmor bug ...

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Is this a privileged container? Can you mount the NFS share manually with the mount command?

Changed in autofs (Ubuntu):
status: New → Incomplete
Revision history for this message
Jens Elkner (jelmd) wrote :

Hmmm, not sure what "privileged container" means. Most machines are on xenial now and use
lxc.aa_profile = lxc-container-default-cgns-with-mounting
if this is the question.

This way mounting manually as well as automatically via automount works, but mounting something via the '-hosts' builtin map still does not work. E.g.:

> df -h
...
software:/export/sfw/share 16T 5.4G 16T 1% /local/share
...

> ls -al /net/software/export/sfw/share
ls: cannot access '/net/software/export/sfw/share': No such file or directory

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

See the last few comments of https://github.com/lxc/lxd/issues/2005

A privileged container is one where the container root user is the real root. In an unprivileged one, root inside the container is just some high-id random user on the host:

root 5393 0.0 0.0 530300 4964 ? Ss jun05 0:00 [lxc monitor] /var/lib/lxd/containers squid-ds216
165536 5414 0.0 0.0 225088 6040 ? Ss jun05 0:00 \_ /sbin/init

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

You can run this to set a container to privileged mode:

lxc config set <container-name> security.privileged true

And then restart it:

lxc restart <container-name>

After that, the users inside the container are no longer mapped to a higher uid:
root 21301 0.0 0.0 602368 6120 ? Ss 17:45 0:00 [lxc monitor] /var/lib/lxd/containers bionic-privileged
root 21322 3.2 0.0 159416 6096 ? Ss 17:45 0:00 \_ /sbin/init
root 21422 0.7 0.0 78304 6320 ? S<s 17:45 0:00 \_ /lib/systemd/systemd-journald
systemd+ 21692 0.2 0.0 80012 3924 ? Ss 17:45 0:00 \_ /lib/systemd/systemd-networkd
...

But something I forgot to clarify: are you using lxc or lxd containers? I assumed lxd. And the host is running what, xenial?

Revision history for this message
Jens Elkner (jelmd) wrote :

Aha - using usually Solaris zones, which have no such distinctions...
Anyway, in this case: yes, all our linux containers are privileged, which seems to be the default.

Revision history for this message
Erik Lönroth (erik-lonroth) wrote :

I get the same issue. I've created systemd unit files for both mount and automount:

$ cat /etc/systemd/system/share-apps.automount
[Unit]
Description=Automount Scratch

[Automount]
Where=/share/apps/

[Install]
WantedBy=multi-user.target

$ cat /etc/systemd/system/share-apps.mount
[Unit]
Description=Scratch

[Mount]
What=192.168.2.241:/mnt/nfs_share
Where=/share/apps
Type=nfs

[Install]
WantedBy=multi-user.target

Mounting works fine (HELLO is a file on the remote NFS server):

$ systemctl start share-apps.mount
$ ls /share/apps/
HELLO

However, automount fails:

$ systemctl stop share-apps.mount
$ ls /share/apps/
$ systemctl start share-apps.automount
Operation on or unit type of share-apps.automount not supported on this system.

$ systemd-detect-virt
lxc

The nfs client container is privilegued.

The nfs client container has these apparmor settings and is restarted with those settings:

lxc config get iceberg:juju-ee5ee4-0 raw.apparmor
mount fstype=rpc_pipefs, mount fstype=nfsd, mount fstype=nfs, mount fstype=nfsv4, mount fstype=autofs,

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.