# Trouble with NFS mount



## hwagemann (Oct 7, 2015)

Hello,

I've made new FreeBSD installations on computer of my wife and on my computer, desktop-installer might be a good tool, but does a little bit too much  I'll write about later.

On both machines I've installed xorg, xfce4, libreoffice, digikam and further software. Both machines are integrated in our lan with nfs shares.
Both machines have same /etc/hosts entries

nfs shares in /etc/fstab of computer of my wife:

```
192.168.1.200:/daten/backup/gerbil  /nas/wdnas  nfs  rw,rsize=8192,wsize=8192 0 0 
taschenmaus.linux.pc:/daten/nutzer/holger  /home/holger/nas  nfs  rw 0 0 
taschenmaus.linux.pc:/daten/nutzer/diane  /home/diane/nas nfs  rw 0 0 
taschenmaus.linux.pc:/daten/nutzer/share  /nas/share  nfs  rw 0 0
```

nfs shares in /etc/fstab of my computer:

```
192.168.1.200:/daten/backup/biber  /nas/wdnas  nfs  rw,rsize=8192,wsize=8192  0  0 
taschenmaus.linux.pc:/daten/nutzer/diane  /home/diane/nas  nfs  rw  0  0 
taschenmaus.linux.pc:/daten/nutzer/holger  /home/holger/nas  nfs  rw  0  0 
taschenmaus.linux.pc:/daten/nutzer/share  /nas/share  nfs  rw  0  0
```

Both machines have same entries in /etc/rc.conf and in /boot/loader.conf

My machine boots in a normal speed. But on computer of my wife boot procedure hangs when trying to mount nfs shares with following message:

```
RPCPROG_NFS: RPC port mapper failure ... RPC: unable to sent
```
After a minute boot procedure continue and after starting wdm the nfs shares are mounted.

How to fix this issue? It seems that on computer of my wife something does not start, what is needed for nfs mount.

Kind regards,
  Holger


----------



## SirDice (Oct 8, 2015)

hwagemann said:


> My machine boots in a normal speed. But on computer of my wife boot procedure hangs when trying to mount nfs shares with following message:
> 
> ```
> RPCPROG_NFS: RPC port mapper failure ... RPC: unable to sent
> ...


It might be due to a firewall. Did you check that?


----------



## hwagemann (Oct 8, 2015)

Hello,

thanks for trying to help me.
Here is /etc/rc.conf of my computer:

```
hostname="biber.linux.pc"
keymap="german.iso.kbd"
ifconfig_em0="inet 192.168.1.102 netmask 255.255.255.0"
defaultrouter="192.168.1.1"
sshd_enable="YES"
moused_enable="YES"
ntpd_enable="YES"
powerd_enable="YES"
devfs_system_ruleset="system"
dumpdev="AUTO"
nfs_client_enable="YES"
dbus_enable="YES"
hald_enable="YES"
cupsd_enable="YES"
cups_browsed_enable="YES"
```

And here is /etc/rc.conf of computer from my wife:

```
hostname="gerbil.linux.pc"
keymap="german.iso.kbd"
ifconfig_re0="inet 192.168.1.101 netmask 255.255.255.0"
defaultrouter="192.168.1.1"
sshd_enable="YES"
moused_enable="YES"
ntpd_enable="YES"
powerd_enable="YES"
devfs_system_ruleset="system"
dumpdev="AUTO"
nfs_client_enable="YES"
dbus_enable="YES"
hald_enable="YES"
cupsd_enable="YES"
cups_browsed_enable="YES"
```

Apart from hostname I cannot see a difference between entries.
On my NAS (Debian GNU/Linux Jessie) with nfs-server there is no firewall configured.
The /etc/exports on my Debian System:

```
/daten/nutzer/share 192.168.1.101(rw,wdelay,sync,subtree_check)
/daten/nutzer/share 192.168.1.102(rw,wdelay,sync,subtree_check)
/daten/nutzer/share 192.168.1.120(rw,wdelay,sync,subtree_check)
/daten/nutzer/holger 192.168.1.101(rw,sync,wdelay,subtree_check,anonuid=1000,anongid=5000)
/daten/nutzer/diane 192.168.1.101(rw,sync,wdelay,subtree_check,anonuid=1001,anongid=5000)
/daten/nutzer/holger 192.168.1.102(rw,sync,wdelay,subtree_check,anonuid=1000,anongid=5000)
/daten/nutzer/diane 192.168.1.102(rw,sync,wdelay,subtree_check,anonuid=1001,anongid=5000)
```

I don't want to change here anything because all our Linux desktop-systems and also FreeBSD desktop-system of my computer work with it.

But during boot procedure of PC from my wife I see something curious. Before the step with NFS access:

```
re0: link state changed to DOWN
```
Is that normal?
Then RPC error message follows, booting stops for a minute, then we get message:

```
re0: link state changed to UP
```
 and when booting has finished, my wife has internet access and also mounted NFS shares.

Sorry, it is a little bit annoying for me, I have spent hours to solve this, I've bought a new PCI network card, I've changed cable.

What can I try next?

Kind regards,
  Holger


----------



## hwagemann (Oct 9, 2015)

Hello,

On PC from my wife network card starts after trying to mount NFS shares, this stops boot procedure for a minute. I can avoid this by adding bg option in fstab:

```
192.168.1.200:/daten/backup/gerbil  /nas/wdnas  nfs  rw,bg,rsize=8192,wsize=8192 0 0
taschenmaus.linux.pc:/daten/nutzer/holger  /home/holger/nas  nfs  rw,bg 0 0
taschenmaus.linux.pc:/daten/nutzer/diane  /home/diane/nas nfs  rw,bg 0 0
taschenmaus.linux.pc:/daten/nutzer/share  /nas/share  nfs  rw,bg 0 0
```

System starts fast but next try for NFS access need some minutes. If I login as root directly after booting and type `mount -a` then I've NFS access immediately.
So where can I place this little command? I've tried /etc/rc.local but found out with `rcorder /etc/rc.d/*` that this script starts before network comes up. Please give me a hint for _a_simple_way_ to execute `mount -a` at end of booting procedure automatically.

Or please give me a hint, if it is possible with further supplements in /etc/fstab to reduce time until next try for NFS mounting.

Sorry, but meanwhile it is 2.30 in the night and I'm a little bit grumpily.

Thanks for your help.

Kind regards,
  Holger


----------



## SirDice (Oct 9, 2015)

Try using the late keyword in the options of /etc/fstab. This will mount the filesystem at a later point in the boot cycle. It's indeed possible it's trying to mount the NFS shares before the network is fully up.

Another option is to use autofs(5) or amd(8). These can automatically mount filesystems when they're accessed.


----------



## hwagemann (Oct 9, 2015)

Hello,

thanks for your hint. Should this mean, that I've to add late option or to replace gb option with it?

Kind regards,
  Holger


----------



## SirDice (Oct 9, 2015)

What bg basically does is to retry mounting it in the background if the initial try failed. That way booting doesn't stop with an error if it failed to mount. The late keyword simply runs the mount later on in the boot process instead of early on. I'd try late first, then perhaps both late and bg. 

I'm wondering why the network comes up so late though. You have static IP addresses so it should be online almost immediately. I've only seen machines taking a while to come up when DHCP is used.


----------



## hwagemann (Oct 10, 2015)

Hello SirDice,

I've tried both, a replacement of bg with late and a combination of bg and late but without success.
With late only:
Systems hangs with known message:

```
RPCPROG_NFS: RPC port mapper failure ... RPC: unable to sent
```

With combination of late and bg:
System boots fast but after start it takes minutes until NFS access becomes ready.



> I'm wondering why the network comes up so late though. You have static IP addresses so it should be online almost immediately. I've only seen machines taking a while to come up when DHCP is used.


This also sometimes happens under GNU/Linux that network card becomes ready after other network dependent stuff. It depends on chip of network card and the module for this chip. On my motherboard there is an Intel chip, on motherboard of computer of my wife is a Realtek chip, to exclude hardware issues I've bought a PCI card from Sitecom with Windows, Linux and FreeBSD support and I've build in this card in computer of my wife. It is also a Realtek chip, so similar situation and same issue during boot procedure. But under Linux there is a very simple solution:
Choosing networkmanager for managing network and internet

```
systemd enable NetworkManager-wait-online.service
```
reboot and network issue has gone

And also with old init system the solution was easy. In /etc/init.d start and stop of services are managed by links, if you have link S99-service-a and link S40-service-b, service-b starts before service-a,  lower number = higher priority

Apart from that I've learned the following: mount under FreeBSD seems to differ from mount under Linux. Under older OpenSUSE systems there is another solution for avoiding trouble with NFS mounting: To add _netdev option in /etc/fstab. I've tried that under FreeBSD but mount of FreeBSD cannot handle it.

But I'll stop now to compare with other Unix derivatives, cause of this issue is known, I'm sure also under FreeBSD this can be solved, and I'm also sure, that there are different ways to solve it, but how can I manage this under FreeBSD?

Kind regards,
  Holger


----------



## UnixRocks (Oct 10, 2015)

You could always create your own init script to put in /usr/local/etc/rc.d/ with a header of: 
	
	



```
# REQUIRE: NETWORKING
```
That then mounts your NFS shares. Call it something like mynfs and enable it in /etc/rc.conf. There are lots of examples of FreeBSD init scripts "out there".


----------



## hwagemann (Oct 11, 2015)

Hello UnixRocks,

Thanks for your hint. I've created a script /usr/local/bin/latemount :

```
#!/bin/sh
mount -a
return 0
```
Then I've created a script /usr/local/etc/rc.d/latemount:

```
#!/bin/sh
# PROVIDE: latemount
# REQUIRE: NETWORKING nfsclient
. /etc/rc.subr
name=latemount
rcvar=latemount_enable
command="/usr/local/bin/${name}"
load_rc_config $name
run_rc_command "$1"
```
Both scripts have following permissions -r-xr-xr-x  1 root  wheel

I've made an entry in /etc/rc.conf:

```
latemount_enable="YES"
```

But after reboot same issue, no mounted NFS shares, appearing of it needs minutes.

When I reboot and do following directly after boot is finished as root :

```
service latemount start
```
then I get NFS access immediately, and no error message or a warning, so syntax of script seems to be proper, *but the script will be ignored during boot procedure*.

Where is the mistake?

Kind regards,
  Holger


----------



## UnixRocks (Oct 11, 2015)

hwagemann said:


> Hello UnixRocks,
> 
> Thanks for your hint. I've created a script /usr/local/bin/latemount :
> 
> ...


Hmmm, okay. Try changing:

```
# REQUIRE: NETWORKING nfsclient
```
To this:

```
# REQUIRE: NETWORKING SERVERS DAEMON LOGIN nfsclient
```
See if that makes any difference.


----------



## hwagemann (Oct 11, 2015)

Hello UnixRocks,

Thanks for further hints, I've learned something about creating init(8) scripts for FreeBSD. But also extended entry for REQUIRE does not help.

I guess it has to do with problems to setup network card with Realtek chip during boot procedure, please compare with this thread:
https://forums.freebsd.org/threads/how-to-get-complete-boot-message.53547

To quote from this thread, following output during boot procedure does not look good:

```
...
Setting hostname: gerbil.linux.pc
re0: link state changed to UP
re0: link state changed to DOWN
Starting Network: lo re0
lo0: blub blub blub
re0: blub blub blub
...
status: no carrier
...
```
And some lines deeper:

```
Mounting NFS .... RPCPROG_NFS: RPC: Portmapper failure - RPC: Unable to send
```

1. Replacing Realtek based network card with Intel based network card to have decent FreeBSD support or
2. Replacing FreeBSD with Linux or
3. Living with this annoying bug ...

I'll decide tomorrow but I'm sure that my wife will not like option three so I'll skip this option.

On my computer with Intel based network card setting up NFS access works like a charm under FreeBSD.

Kind regards,
  Holger


----------



## UnixRocks (Oct 12, 2015)

Well, hwagemann, if you have determined it is the Realtek chip giving you trouble then #1 in your list should resolve your problem. It is not like network cards for consumer hardware are all that costly.


----------



## Datapanic (Jul 9, 2016)

I ran into this same problem with NFS remote mounts and logging to a remote SYSLOG server and also have Realtek NIC built in to the system board and no option to install a different NIC.  After digging around a bit, I found my solution to be adding the following to /etc/rc.conf:


```
#
# NETWAIT
#
netwait_enable="YES"  # Enable rc.d/netwait (or NO)
netwait_ip="10.0.0.1"  # IP addresses to be pinged by netwait.
netwait_timeout="60"  # Total number of seconds to perform pings.
netwait_if="re0"  # Interface name to watch link state on.
netwait_if_timeout="30"  # Total number of seconds to monitor link state.
```

Of course substitute a pingable IP address on your network (or even outside) for the `netwait_ip` parameter.

Oddly enough, this only started happening when I replaced the disk drive with a 240GB SSD.  Before, it had a 1TB spinning drive and the boot up worked fine.  Maybe the slower performance of the older drive caused enough of a delay in bootup that the NIC was UP by the time it was needed for the remote mounts and syslog.


----------

