nfs export over multiple filesystems is no longer working since last kernel update

Asked by Rainer

Hi all,

since years, i run a 14.04 LTS server which exports

/media/

to one nfs client.

In fact, below /media/servername there is a bunch of mountpoints for lokal filesystems:
/media/disk1
/media/disk2
...
/media/disk8

On the client side, it worked perfectly to

mount -t nfs servername:/media /media/servername

to get access to all of the above named filesystems.

Since the last update on the server two days ago (with new kernel version 3.13.0-92) this does no longer work.
The mount itself is without any problem. But if i try to change to the directory

/media/servername/disk1

i get a "Operation not permitted" error message.

The /etc/exports file was:

/media client(rw,async,crossmnt)

I already tried (according to some hints i found):

/media client(rw,async,crossmnt)
/media/disk1 client(rw,async,crossmnt)
/media/disk2 client(rw,async,crossmnt)
...

The problem remains the same.
The only working solution is to export and mount every single filesystem seperately.

Is there any chance to get the "old" behaviour back. (And yes, i know there is a problem with inode number collision in my scenario.)

Best regards,
Rainer

Question information

Language:
English Edit question
Status:
Expired
For:
Ubuntu linux Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said :
#1

If you boot an older kernel is it OK?

Revision history for this message
Rainer (rainer-peipp) said :
#2

Good hint. So i tried the following:
Booting the nfs server with the older kernel 3.13.0-91 doesn't change anything.

The problem seems to be on the client side:
If i step back to the kernel 4.4.0-28 on the client, the problem is solved!
With the current kernel for 16.04 (4.4.0-31-generic) the problem is back again!

So, is there any chance to get more details (logs, ...) to support the analysis?

Best regards,
Rainer

Revision history for this message
actionparsnip (andrew-woodhead666) said :
#3

Possibly the output of:

dmesg

After each boot with each kernel. If the kernel you have is working then you can apt-pin it and it won't upgrade

Revision history for this message
Rainer (rainer-peipp) said :
#4

Within the 1286 lines of output of dmesg there are only a few lines, which are (for me) NFS related:

[ 16.077398] RPC: Registered tcp NFSv4.1 backchannel transport module.
...
[ 61.658167] FS-Cache: Netfs 'nfs' registered for caching
[ 61.677420] NFS: Registering the id_resolver key type
[ 61.677434] Key type id_resolver registered
[ 61.677436] Key type id_legacy registered

I can not see any "error" related information.

Best reagards,
Rainer

Revision history for this message
Manfred Hampl (m-hampl) said :
#5

Is this the dmesg output from the server or the client?
If you guess that the problem might be on the client side, then you should look into the dmesg output of the client and compare the output of a working version (older kernel) with a broken one.

I have not identified anything in the change log of the kernel packages between 4.4.0-28 and 4.4.0-31 that would explain this different behavior w.r.t. nfs.

Revision history for this message
Rainer (rainer-peipp) said :
#6

This was the output of the client. I have also tried to compare the output of dmesg between 4.4.0-28 and 4.4.0-31. Although there are some differences, i can not see any w.r.t. nfs. The dmesg logs are available but a little bit to large to post them.

Best reagards,
Rainer

Revision history for this message
Launchpad Janitor (janitor) said :
#7

This question was expired because it remained in the 'Open' state without activity for the last 15 days.