nfs-kernel-server, several shares in /etc/exports shows same partition on client

Bug #436527 reported by Petter Aas
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
nfs-utils (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: nfs-kernel-server

after updating a private file-server from 9.04 to 9.10 I got a strange problem with my nfs shares on it,

/etc/exports :
/pub2 10.0.0.0/24(rw,sync,fsid=0,crossmnt,subtree_check)
/pub 10.0.0.0/24(rw,sync,fsid=0,crossmnt,subtree_check)
/p 10.0.0.0/24(rw,sync,fsid=0,crossmnt,subtree_check)

df -hT on nfs server:
/dev/md6 ext4 1,8T 915G 827G 53% /pub2
/dev/sdg btrfs 2,3T 1,1T 1,2T 48% /pub
/dev/sde1 reiserfs 299G 55G 244G 19% /p

df -hT on a client with nfs shares from the server:
10.0.0.2:/pub nfs 1,8T 915G 827G 53% /pub
10.0.0.2:/pub2 nfs 1,8T 915G 827G 53% /pub2
10.0.0.2:/p nfs 1,8T 915G 827G 53% /p

( ps: look at disk sizes)

( I have three client with the same result, one 9.04, one 9.10 and a PopCornHour A110)

so you see that the client gets three version of 'pub2' under the 'correct' names, if I resort /etc/exports to something else like

/p 10.0.0.0/24(rw,sync,fsid=0,crossmnt,subtree_check)
/pub2 10.0.0.0/24(rw,sync,fsid=0,crossmnt,subtree_check)
/pub 10.0.0.0/24(rw,sync,fsid=0,crossmnt,subtree_check)

the client will get three versions of '/p' still with the 'correct' names. Except for sorting the shares in various ways, I have not done any other changes to /etc/exports after updating from 9.04 to 9.10...

Some info from nfs server, please ask for more if needed:
dpkg -l | grep nfs:
ii libnfsidmap2 0.21-2 An nfs idmapping library
ii nfs-common 1:1.2.0-2 NFS support files common to client and serve
ii nfs-kernel-server 1:1.2.0-2 support for NFS kernel server

uname -a
Linux zoidberg 2.6.31-10-generic #35-Ubuntu SMP Tue Sep 22 17:33:42 UTC 2009 i686 GNU/Linux

lsb_release -rd:
Description: Ubuntu karmic (development branch)
Release: 9.10

apt-cache policy nfs-kernel-server
nfs-kernel-server:
  Installert: 1:1.2.0-2
  Kandidat: 1:1.2.0-2
  Versjonstabell:
 *** 1:1.2.0-2 0
        500 http://no.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

nfs-common:
  Installert: 1:1.2.0-2
  Kandidat: 1:1.2.0-2
  Versjonstabell:
 *** 1:1.2.0-2 0
        500 http://no.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

One of the clients: (this is still 9.04)
dpkg -l | grep nfs
ii libnfsidmap2 0.21-2 An nfs idmapping library
ii nfs-common 1:1.1.4-1ubuntu1 NFS support files common to client and serve
ii nfs-kernel-server 1:1.1.4-1ubuntu1 support for NFS kernel server

uname -a
Linux desk1 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux

lsb_release -rd

I know that btrfs, which i use on /pub, is alpha, but I get the same problem when taking that out of exports.

And finally I couldn't find any bugs even close to this, but please tell me If I've overlooked one...

Revision history for this message
Petter Aas (petteraas) wrote :

update:

 I've just found this in /var/log/daemon.log on nfs server

Sep 26 00:01:11 nfs-server mountd[8861]: /pub2 and /pub have same filehandle for 10.0.0.0/24, using first
Sep 26 00:01:11 nfs-server mountd[8861]: /pub2 and /private have same filehandle for 10.0.0.0/24, using first

has there been any significant changes to the way /etc/exports is supposed to look like in ubuntu 9.10?

Revision history for this message
Petter Aas (petteraas) wrote :

update:

I removed my existing /etc/exports and wrote a new one after reading http://www.ubuntugeek.com/nfs-server-and-client-configuration-in-ubuntu.html

:

/pub 10.0.0.0/24(rw,no_root_squash,no_subtree_check)
/pub2 10.0.0.0/24(rw,no_root_squash,no_subtree_check)
/p 10.0.0.0/24(rw,no_root_squash,no_subtree_check)

df -hT on client now:
10.0.0.2:/pub nfs 2,3T 1,1T 1,2T 48% /pub
10.0.0.2:/pub2 nfs 1,8T 915G 827G 53% /pub2
10.0.0.2:/p nfs 299G 49G 250G 17% /p

so perhaps its not a bug afterall, but I still find it peculiar that my old exports worked in 9.04 and not 9.10...

Revision history for this message
mckemie (mckemie) wrote :

I have a possibly related bug. I use a very old NFS server running Caldera OpenLinux from 1998. It mounted fine on Ubuntu 9.04 and many other Linux flavors. However, after upgrading from 9.04 to 9.10, it no longer mounts but fails with the message "failed: RPC Error: Success"

Revision history for this message
Antonio J. de Oliveira (ajoliveira) wrote :

I fixed this by rewriting /etc/exports on a lucid client, the "same filehandle" message was there and vanished afterwards, but could not do anything on karmic clients, so I am forcing an unwanted lucid upgrade on the server (server kernel). This is a major bug, I will keep you posted about the behavior on lucid, 9.10 is not suitable for servers using nfs shares.

Changed in nfs-utils (Ubuntu):
status: New → Confirmed
Revision history for this message
Antonio J. de Oliveira (ajoliveira) wrote :

correcting previous info, "same filehandle" warning still exists for karmic clients, only ceased to exist for lucid clients.

Revision history for this message
Antonio J. de Oliveira (ajoliveira) wrote :

ok, here goes:

after the lucid server upgrade, situation was identical, karmic and lucid 32-bit clients had duplicate exports. lucid 64-bit client worked flawlessly.

took out fsid=0, and everything went back to normal

(rw,sync,crossmnt,no_subtree_check) instead of (rw,fsid=0,sync,crossmnt,no_subtree_check)

fsid=0 has the meaning of identifying the export as root. Multiple exports cannot be made this way. What I suggest is that a warning should be given by exportfs when using multiple fsid=0 export entries.

Technically this does not seem to be a bug, but a nagging annoyance caused by the parser being unprotected against inherited malpractice, so turning into one.

I would like to hear your opinion on this, particularly the developer's opinion.

All the best
Antonio

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.