# Troubles exporting NFS-shares

## neonknight

Whenever I try to export shares for NFS, it takes ages (= the timeout from /etc/conf.d/nfs) and ends in an errormessage:

 *Quote:*   

> twilight ~ # /etc/init.d/nfs start
> 
>  * Exporting NFS directories ...
> 
> /etc/init.d/nfs: line 65:  2980 Getötet                 $exportfs -r 1>&2
> ...

 

Getötet = killed

my /etc/exports:

 *Quote:*   

> /mnt/mp3                192.168.0.0/24(ro,sync,no_root_squash)
> 
> /mnt/filme              192.168.0.0/24(ro,sync,no_root_squash)
> 
> /mnt/35gb               aurora(rw,sync,no_root_squash) 
> ...

 

Kernel-config (2.6.9-gentoo-r6):

* NFS Server support

* Provide NFSv3 server support

* Provide NFS server over TCP support

The interesting fact: Despite this message, everything is exported as desired.

morningstar and aurora have their entries in /etc/hosts and are resolved correctly.

Is there anything wrong?

----------

## Daemonax

Have you started nfs on your other machine? And have you editted hosts.allow? I found that you had to edit that before it would work.

----------

## neonknight

On morningstar, nfs has already been started when I try to export on my machine. Aurora is a Laptop and therefore not always in the network. But that should really not be a problem, as I can export on morningstar as I like - there it exports as fast as it should.

I didn't have an /etc/hosts.allow, so I created it. But here too, I can't imagine why this should solve the problem... (and it also didn't do so...)

But thank you for your hints!

----------

## macawgumbo

try doing 

```
emerge -davu nfs-utils
```

 to update your nfs utilities.

----------

## neonknight

nfs-utils is already the newest (stable = x86) version.

I did an emerge -eDav nfs-utils a few days ago, which did not help either.

----------

## Modula

Is portmapper running on both server and client?

check with:

```
rpcinfo -p <server>
```

and

```
rpcinfo -p <client>
```

It should show something like:

 *Quote:*   

> 
> 
> bash-2.05b$ /usr/sbin/rpcinfo -p orion
> 
> program vers proto   port
> ...

 

Look at http://nfs.sourceforge.net/nfs-howto/server.html and http://nfs.sourceforge.net/nfs-howto/client.html for more information.

----------

## neonknight

Yes, portmapper is running on all machines

But I still don't get what the client has to do with the problems of the server? Actually, the server should be able to export the filesystems in /etc/exports by executing exportfs -r independent of how the clients are configured...

----------

## gymer

Try running exportfs manually

try:

exportfs -r -v 

v for verbose:

Be verbose. When exporting or unexporting, show what's going on. When displaying the current export list, also display the list of export options.

----------

## neonknight

This is what I get:

twilight ~ # exportfs -rv

[10s break]

exporting morningstar:/home/morningstar

exporting 192.168.0.10:/home/neonknight

exporting aurora:/home/neonknight

exporting aurora:/mnt/35gb

exporting 192.168.0.0/24:/mnt/35gb/Programme

exporting 192.168.0.0/24:/mnt/filme

exporting 192.168.0.0/24:/mnt/mp3

[15s break]

twilight ~ #

so it exports, but it has two long do_nothing_loops() in there... btw: there are no messages in /var/log/messages and cpu utilisation remains zero in this time

----------

## gymer

Try a quick and dirty hack.

edit /etc/conf.d/nfs

find:

```

EXPORTFSTIMEOUT=30

```

replace with

```

EXPORTFSTIMEOUT=60

```

then try restarting nfs (/etc/init.d/nfs restart)

----------

## neonknight

Now the timeout is long enough to make the errormessage disappear, but of course exporting now takes even longer than before. See, this is what sucks... If nfs is in my runlevel, booting the box takes ages. So this cannot be the final solution.

And I'm also curious to know why it takes so long  :Wink: 

----------

## Crisis

could it possibly be trying to resolve IPs for those hosts you call by name in the exports?  Maybe try replacing them with IPs for now and see if it speeds it up?

----------

## neonknight

Already tried that... makes no difference at all  :Sad: 

----------

## spacebar

hi, i've been having the same problem.

i was wondering if by chance you already had the network clients defined in your /etc/hosts file. i just added entries for mine and it seemed to resolve this issue. nfs starts quickly now like it's supposed to.

--D

----------

## neonknight

 *spacebar wrote:*   

> i was wondering if by chance you already had the network clients defined in your /etc/hosts file.

 

of course  :Very Happy: 

----------

## wolvenwraith

I just ran into this issue... Turns out, I moved DNS servers from 192.168.1.21 to 192.168.1.1, and I forgot to update /etc/resolv.conf on the NFS server. The server then kept trying to resolve client addresses, and freezing up (since I took down .21)

So it seems that this issue is entirely DNS related.

----------

## neonknight

I just found out, that my provider has disabled one of their nameservers... Of course the one I entered as my primary DNS-server. I have corrected my /etc/resolv.conf and now it works. Thanks for your hint, wolvenwraith

But: why the fsck does nfs need a DNS-server in the internet to start properly?

----------

## richardash1981

The nfs server needs to be able to do a reverse DNS lookup on each client IP that tries to connect to it,(even with IP addresses or masks in /etc/exports).  If it can't, mount will often time out on the clients, and exportfs will take much longer.

You don't need an internet DNS if the clients are in the server's hosts file.

----------

