DNS Fails for NFS Server Shares

userlander · 2008-11-09 16:07:54

When I boot, I get a message that DNS has failed for the NFS server mounts, and the shares do not mount. The message says, "mount.nfs: DNS resolution failed for server: name or service unknown." I have to mount the shares myself. Then when rebooting, I get the same error saying it can't unmount the shares.

this is /etc/resolv.conf:

$ cat /etc/resolv.conf
# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
nameserver 208.67.222.222
nameserver 208.67.220.220
# /etc/resolv.conf.tail can replace this line

this is /etc/conf.d/nfs:

# Number of servers to be started up by default
NFSD_OPTS=8

# Options to pass to rpc.mountd
# e.g. MOUNTDOPTS="-p 32767"
MOUNTD_OPTS="--no-nfs-version 1 --no-nfs-version 2"

# Options to pass to rpc.statd
# N.B. statd normally runs on both client and server, and run-time
# options should be specified accordingly. Specifically, the Arch
# NFS init scripts require the --no-notify flag on the server,
# but not on the client e.g.
# STATD_OPTS="--no-notify -p 32765 -o 32766" -> server
# STATD_OPTS="-p 32765 -o 32766" -> client
STATD_OPTS=""

# Options to pass to sm-notify
# e.g. SMNOTIFY_OPTS="-p 32764"
SMNOTIFY_OPTS=""

Do I need to add some option to rpc.statd, or is there some other misconfiguration there? AFAIK it is the default. What else should I look at to fix this? I can ping the server by name, and log in with ssh by name, just fine. It's only the nfs that is failing with DNS.

userlander · 2008-11-19 13:50:19

No one knows why? I think it must be the dhcpcd.conf because my resolv.conf keeps getting changed, but I can't figure out how to fix it.

tomk · 2008-11-19 15:03:02

If you don't want resolv.conf to change, use the -C/--nohook option in /etc/conf.d/dhcpcd. man dhcpcd for full details.

userlander · 2008-11-19 18:53:46

Would having just openDNS nameservers and no search line in resolv.conf cause the NFS DNS resolution to fail?

userlander · 2008-11-19 19:14:52

I added "search localhost" to resolv.conf, and when I rebooted it mounted the shares. Then I rebooted again with --nohook to test it, and with that option it writes a blank resolv.conf file. There used to be some dhcpcd option to just leave resolv.conf alone -- -R or something -- what happened to that? Now it seems it either rewrites resolv.conf to just the 2 openDNS servers, or else with --nohook gives you a blank resolv.conf and you can't even resolve anywhere. I don't see anything in man dhcpcd.conf about telling it not to mess with your resolv.conf file at all. where is that option? :?:

tomk · 2008-11-19 22:28:39

There is an example in the man page:

−C, −‐nohook script
Don't run this hook script. Matches full name, or prefixed
with 2 numbers optionally ending with .sh.
So to stop dhcpcd from touching your DNS or MTU settings you
would do:‐
dhcpcd ‐C resolv.conf ‐C mtu eth0

userlander · 2008-12-05 15:13:31

Nothing really seems to help. I don't think it's DNS but a bug in NFS. I changed the fstab lines from using the name to the IP of the computer, and it still fails in the same way.

mount.nfs: DNS resolution failed for 192.168.0.113: name or service unknown

airman99 · 2008-12-24 14:01:53

I'm having the exact same problem on a laptop of mine (the only computer I have that currently uses NFS). Upon bootup, all NFS shares in /etc/fstab fail to mount with the above error. Changing the NFS host name in fstab to its IP address does not help, same error.

After bootup, a '%mount -a' mounts the NFS shares without a problem.

As many people use NFS, we can't be the only 2 people having this problem...

Ideas?

Last edited by airman99 (2009-01-11 15:56:15)

airman99 · 2008-12-25 00:24:11

The same error occurs upon shutdown of the machine also.

Is there anybody running current arch and NFS who is automounting NFS shares on bootup and NOT having this problem? If so, if you could post the NFS version, as well as your /etc/fstab, that would be useful...

airman99 · 2009-01-11 19:19:38

Yahoo! Good news, I've finally solved the problem on my laptop. The message I was receiving turned out merely to be a network timing issue.

The error I was receiving was exactly correct and informative. When /etc/rc.d/netfs ran and executed a 'mount -a -t nfs...' the network was indeed NOT reachable. I am running networkmanager, and apparently during bootup, networkmanager gets loaded, but there is a delay between when networkmanager is loaded and when the network is available. In other words, networkmanager allows the boot process to continue before the network is available.

My daemons are loaded in this order (rc.conf):

DAEMONS=(syslog-ng  hal dhcdbd networkmanager  crond  cups  ntpdate ntpd  portmap nfslock netfs)

Consequently, if I add a delay to /etc/rc.d/netfs to allow time for the network to come up, then when the NFS shares are mounted, the network is up. In my case I had to add a 3 second delay.

sleep 3

I'm sure this isn't the best way to solve the problem, by editing the system file /etc/rc.d/netfs, because the next upgrade where changes occur to netfs, my fix will get overwritten. But I'll keep it until I figure out the "right" fix.

The real solution is to not load networkmanager in the background, but to force startup to wait for the networok to be up before continuing.

Last edited by airman99 (2009-01-11 19:20:09)

cu3edweb · 2009-02-20 14:33:22

I am having this problem also. I use wicd and have it earlier in my daemon list in rc.conf. I had the sleep trick working with my old setup but I did a reinstall and now I can't seem to get the sleep trick to work. It seems there should be a better way then than sleeping the nsfd though.

Convergence · 2009-02-25 15:17:27

Thanks airman, your sleep trick works for me. I've never used the '@' token to run wicd in the background, so wicd must allow other services to start before it is finished anyway. I bet that this behaviour causes other problems as well as this one.

cu3edweb: remind me not to reinstall!

greenfish · 2009-05-24 18:20:20

I just re-installed my entire system again thanks to ATI (dont ask) anyways i'm having the exact same issue but I use netcfg. Tried using the sleep trick but i'm still getting the same error.

I guess i'll just write a script that mounts the nfs path manually instead. But that's a bit unclean don't you think? Using a hack to jump start another hack, grrrrrrrrrrrrrrrrrrr. :rolleyes:

"umount.nfs server faild to unmount" great i'll hack shutdown to kill the server point as well, what the hell seriously

NFS4 isnt even an option for me, the motd daemon is broken on my system

EDIT: both my scripts or hacks works but it's a dirty trick to make it work also it slows down my boot since i have to add a sleep counter on my first script.

Last edited by greenfish (2009-05-24 18:31:01)

stefanwilkens · 2009-05-24 19:05:42

airman99 wrote:

Yahoo! Good news, I've finally solved the problem on my laptop. The message I was receiving turned out merely to be a network timing issue.
The error I was receiving was exactly correct and informative. When /etc/rc.d/netfs ran and executed a 'mount -a -t nfs...' the network was indeed NOT reachable. I am running networkmanager, and apparently during bootup, networkmanager gets loaded, but there is a delay between when networkmanager is loaded and when the network is available. In other words, networkmanager allows the boot process to continue before the network is available.
My daemons are loaded in this order (rc.conf):
DAEMONS=(syslog-ng  hal dhcdbd networkmanager  crond  cups  ntpdate ntpd  portmap nfslock netfs)
Consequently, if I add a delay to /etc/rc.d/netfs to allow time for the network to come up, then when the NFS shares are mounted, the network is up. In my case I had to add a 3 second delay.
sleep 3
I'm sure this isn't the best way to solve the problem, by editing the system file /etc/rc.d/netfs, because the next upgrade where changes occur to netfs, my fix will get overwritten. But I'll keep it until I figure out the "right" fix.
The real solution is to not load networkmanager in the background, but to force startup to wait for the networok to be up before continuing.

there is the _netdev option you can use in fstab, but that doesn't always work:
http://linux.die.net/man/8/mount

_netdev
The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system).

Alternatively, you could just add a cronjob to do a mount -a with a sleep 20 in there or something. You might have to play with the sleep value a little to make sure it's long enough

peque · 2009-10-06 08:35:48

I experimce the same problem.
I have in my MythTV setup a NAS-server with 2x1TB in RAID1.
The NAS are storing all the concerts and movies to my MythTV system, but are suddenly stopped to get mounted at boottime - and afterwards it isn't possible to mount it manually ???

just getting this error:

mount.nfs: DNS resolution failed for HOSTNAME/IP-Address

I've tried the answers as suggested - but no change - the drive will not be mounted - I've testet it through its interface - everything is working fine - without any errors. The IP address is the same as allways!
What could carse this to stop working?

Last edited by peque (2009-10-06 08:40:47)

vacant · 2009-10-06 09:16:57

To anyone using wicd and having to add a "sleep" to give the network time to come up:

In wicd-client, click on the connection's "properties" -> "scripts" -> "post connection scripts" and add your daemons there.

I found openntpd failing so took stuff out of rc.conf daemons and added a post connection script e.g.: "/etc/rc.d/dnsmasq start && /etc/rc.d/openntpd start"

zenlord · 2010-02-23 19:50:59

I'm having the same issue, but only when shutting down.

I tried adding a POST_DOWN="/etc/rc.d/nfs-common stop 2>/dev/null;" to my netcfg-profile, but it seems that the shutdown sequence doesn't wait for this to happen.

Anyone?

Last edited by zenlord (2010-02-23 19:51:20)

Arch Linux

#1 2008-11-09 16:07:54

DNS Fails for NFS Server Shares

#2 2008-11-19 13:50:19

Re: DNS Fails for NFS Server Shares

#3 2008-11-19 15:03:02

Re: DNS Fails for NFS Server Shares

#4 2008-11-19 18:53:46

Re: DNS Fails for NFS Server Shares

#5 2008-11-19 19:14:52

Re: DNS Fails for NFS Server Shares

#6 2008-11-19 22:28:39

Re: DNS Fails for NFS Server Shares

#7 2008-12-05 15:13:31

Re: DNS Fails for NFS Server Shares

#8 2008-12-24 14:01:53

Re: DNS Fails for NFS Server Shares

#9 2008-12-25 00:24:11

Re: DNS Fails for NFS Server Shares

#10 2009-01-11 19:19:38

Re: DNS Fails for NFS Server Shares

#11 2009-02-20 14:33:22

Re: DNS Fails for NFS Server Shares

#12 2009-02-25 15:17:27

Re: DNS Fails for NFS Server Shares

#13 2009-05-24 18:20:20

Re: DNS Fails for NFS Server Shares

#14 2009-05-24 19:05:42

Re: DNS Fails for NFS Server Shares

#15 2009-10-06 08:35:48

Re: DNS Fails for NFS Server Shares

#16 2009-10-06 09:16:57

Re: DNS Fails for NFS Server Shares

#17 2010-02-23 19:50:59

Re: DNS Fails for NFS Server Shares

Board footer