I have the following in /etc/fstab on FreeBSD:

venture:/usr/redacted    /usr/local/redacted   nfs     rw      0       0

This fails during boot. However, after boot, the following command succeeds

mount -t nfs venture:/usr/redacted /usr/local/redacted

Two related questions:

1) last time I rebooted at the console (this machine is in a datacenter), I'm pretty sure I saw an explanatory message at boot time regarding the failure to mount. I think it had something to do with resolving the hostname. However, this message does not appear in /var/log/messages with other boot-time messages; is there someplace else I should be looking?

2) Any thoughts about what could be preventing the hostname from resolving at boot time, but no problem 30 seconds later from the command prompt?

  • 4
    Maybe its trying to mount before a local name service of some sort is up? (Local DNS server, etc.)
    – derobert
    Commented Mar 8, 2013 at 18:39
  • Heh. Good thought. I was going to respond that "venture" is in the hosts file, but I checked and, no, it isn't. The local DNS server is dnscache, started by svscan late in the boot process, so I bet that's the problem. I'm adding venture to the hosts file for now and we'll see after next reboot whether that fixes the problem. Meanwhile, I'm still interested in an answer (if there is one) to my logging question.
    – davidcl
    Commented Mar 8, 2013 at 19:17
  • 1
    No thoughts on the logging issue. I just think that a better solution to your mount failure problem is to start the nfs client after any networking services. Worked for me in the past... If that isn't an option, a dirty workaround that also helped me before is to add this to your /etc/rc.local: mountpoint /usr/redacted || mount /usr/redacted
    – Joseph R.
    Commented Mar 8, 2013 at 21:44
  • @Joseph R: I'm not sure how to make a system service in /etc/rc.d start after a local service in /usr/local/etc/rc.d
    – davidcl
    Commented Mar 8, 2013 at 22:16
  • Which version of FreeBSD are you using? Commented Mar 9, 2013 at 23:34

4 Answers 4


The network sometimes isn't fully functional (e.g. DNS) before the mount is attempted. You can add options in /etc/fstab to mitigate this. Either or both may work for you (I use both):

venture:/usr/redacted    /usr/local/redacted   nfs     rw,late,bg      0       0  

These are the late option (try later in the boot sequence rather than earlier), and bg (keep trying in the background).


I had several servers that showed the same behavior, network/local resolvers not started when the NFS mount is being accessed. The solution was changing service start. Not sure about freebsd, but that should give you a starting point.

  • Rather than changing the order of the services (which is a big change that may break other things), simply adding the server's details in /etc/hosts seems to be a better option.
    – Kusalananda
    Commented May 9, 2017 at 16:16

You can check kernel messages. In centOS or redhat, these logs are located in /var/log/dmesg.

It may happen that during boot, before network services are up, server is trying to boot NFS storage and it is unable to resolve remote host.

You can also check by changing start time of NFS service at last.


You can try looking in /var/log/boot.msg and boot.msg, they will contain the text you see on the screen while booting up.

My guess is it might have something to do with runlevel 3 versus runlevel 5, and that you might be trying to nfs mount something listed in the /etc/fstab file before all other required services have been started.

Instead of using the hostname venture in /etc/fstab you can try using it's ip address instead. That would quickly verify it is a hostname or dns lookup problem. You might be able to fix this by adding venture and it's ip address in /etc/hosts, but that would only work if you know venture won't have its ip address by dhcp.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .