On 06/26/2015 07:44 PM, Arno Schuring wrote:
>> From: svenjoac@gmx.de
>> Date: Fri, 26 Jun 2015 19:28:37 +0200
>> On 2015-06-26 18:38 +0200, Jonas Meurer wrote:
>>>> Process: 352 ExecMount=/bin/mount -n nfs-server:/vmail /var/vmail
>>>> -t
>>>> nfs4 -o sec=krb5i,_netdev (code=exited, status=32)
>>>>
>>>> Jun 26 16:29:02 clt mount[352]: mount.nfs4: an incorrect mount
>>>> option was specified
>>
>> mount.nfs4 prints this not very enlightening message if the mount
>> syscall fails with EINVAL.
>
> If I've understood the mount scripts correctly, the error is correct:
> the _netdev mount option is for mount scripts only, and should /not/
> be passed to the mount command.
Not quite. mount(8) and mount.nfs4(8) do understand and ignore the
_netdev option (at least in Jessie's version [1]), so they don't need
to be filtered.
Also:
- _netdev is not required for nfs4/nfs filesystems, systemd has a
whitelist of filesystems it implicitly considers network
filesystems, and nfs4 is among them [2]
Also, if systemd hadn't detected it to be a network filesystem, it
would have assumed it to be a local filesystem - and for failing
local filesystems systemd drops you in an emergency shell, so the
systemd wouldn't even have booted then.
_netdev does have its uses [3], but not for a typical NFS mount.
- the same error also occurs in the original poster's message when
_netdev was not specified, so it doesn't have to do anything with
this option
> I would guess that this is another case where systemd breaks
> backwards compatibility. Maybe it's mentioned in the release notes?
No, systemd is not at fault here. (See above.)
With respect to the original problem:
Q1. Does it mount manually after boot?
What does mount /var/vmail say?
If it works, skip to Q5, if not, check the following:
Q2. You have a krb5 mount, do you have NEED_GSSD=1 in
/etc/default/nfs-common? Also, while that should'nt affect the
mount itself, sec=krb5 mounts also need the idmapper to work
properly, so do you have NEED_IDMAPD=yes in there?
Q3. Is your /etc/krb5.keytab set up properly? What does
klist -k /etc/krb5.keytab say?
Q4. What do the NFS server's logs say? Is there any indication there
about the failed mount?
[From here on assuming that the manual mount works:]
Q5. What kind of network configuration do you use? It may be the case
that you didn't tell it to make systemd wait for it to be online
before attempting to mount stuff.[4] Scenarios:
- you are using NetworkManager. In that case, you need to enable the
service that tells systemd to wait for the networking to come up:
systemctl enable NetworkManager-wait-online.service
- you are using systemd-networkd. Same logic, different service:
systemctl enable systemd-networkd-wait-online.service
- you are using /etc/network/interfaces and have allow-hotplug eth0
(or whatever your interface is called) in there
Unfortunately, /etc/network/interfaces is Debian-specific and they
don't have a hook for allow-hotplug interfaces w.r.t. the
network-online.target logic of systemd
However, since you need the interface at boot anyway, you don't
need allow-hotplug, you can just change it to auto, e.g.:
allow-hotplug eth0 -> auto eth0 in /etc/network/interfaces
Then /etc/init.d/networking (which is used to set up the
interfaces in Debian from /etc/network/interfaces) will wait until
the interface is up before continuing
- On some systems with static IP addresses (and
/etc/network/interfaces), I had the problem that even though the
interface was conisdered up and ready by the kernel, the switch it
was connected to needed 30s or so to realize that fully (and
packets were simply dropped beforehand). Since those systems also
needed to mount NFS, on Jessie systems I use the following unit
file to try to ping the NFS server before systemd should continue
with NFS mounts:
# /etc/systemd/system/wait-for-nfs-server.service
[Unit]
Description=Waiting for NFS server
DefaultDependencies=no
Conflicts=shutdown.target
Wants=network-online.target
Before=network-online.target shutdown.target
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c "while ! ping -c 1 HOST_NAME_OF_NFS_SERVER >/dev/null; do sleep 1; done"
# Modify this timeout to your heart's content.
TimeoutStartSec=60
[Install]
WantedBy=network.target
(And after that: systemctl enable wait-for-nfs-server.service)
Hope that helps.
Christian
[1] Here's the source code for that and you can see that it understands
the option:
http://sources.debian.net/src/nfs-utils/1:1.2.8-9/utils/mount/mount.c/#L112
[2] Source code:
http://sources.debian.net/src/systemd/215-17%2Bdeb8u1/src/shared/util.c/#L1543
[3] _netdev is useful in 3 use cases:
- you have a network filesystem (e.g. via FUSE) that is not known
by the systemd devs at the time the version of systemd was
released that you are using, so it isn't detected
(or the initscripts for that matter if you don't use systemd,
the systemd people didn't invent _netdev, that was already
supported way back then)
- you have regular filesystems on virtual block devices that
require network (NBD, iSCSI, etc.)
- you have regular filesystems that should be mounted to a mount
point that resides on a network filesystem,
e.g. /srv is on NFS, /srv/local is ext4 on the local hdd,
but /srv needs to be mounted before /srv/local can be, so
you need to mark /srv/local _netdev for this to work
properly
[4] See also:
http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Attachment:
signature.asc
Description: OpenPGP digital signature