Bug 814418

Just a quick update so you know that the problem is being
worked on and we're making progress.

I've worked through the reproducer above and I'm able to
reproduce the problem.

I tried reverting a patch but that didn't help which really
only leaves one patch that could be a problem.

I've built a kernel (but not yet tested) without the patch for
handling the automount of paths with a trailing "/", which I
expect is the cause.

I believe that the problem is miss handling of the trailing
"/" in the kernel path walk of the arguments of the command
"ln -s ../nool/web/ html" since using "ln -s ../nool/web html"
doesn't expose the problem.

Created attachment 580720 [details]
Patch - propogate LOOKUP_DIRECTORY flag only for last component

A kernel that should resolve this problem is available at:
http://people.redhat.com/~ikent/kernel-2.6.18-308.5.1.el5.bz814418.3

It includes the patch posted in comment #3.
Please test this kernel and report back.

This kernel is working on my current setup. Thanks for getting on this.

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

I have just noticed after the recent kernel update that the error only occurs on the PAE kernel, where the kernel you had put up was a non-PAE kernel. So, the fix you put up did fix the problem, but it is possible it was for the wrong reason.

(In reply to comment #8)
> I have just noticed after the recent kernel update that the error only
> occurs on the PAE kernel, where the kernel you had put up was a non-PAE
> kernel. So, the fix you put up did fix the problem, but it is possible it
> was for the wrong reason.

I think you're mistaken.

I'm a litle behind on this one as I haven't yet sent the patch
to the kernel patch review list so it can't be included in the
kerel source tree.

But, more importantly, this won't get pushed out in an update
unless someone adds the ZStream keyword to the bug attributes
and it is then approved and the bug cloned to get the update
underway. Ideally that keyword would be set before I post the
patch so that the ZStream update request gets noticed at the
same time as the patch is posted. I believe I don't have the
ability to set the ZStream keyword so someone else (anyone,
please) will need to do that.

Hi Ian,
Is there anything I can do to have this fixed asap? This bug is very annoying for us as it prevents us from upgrading to the latest kernel. I took matter-of-fact that is going to be fixed in 2.6.18-308.5.1.el5 kernels (no, we are not using the PAE kernel, but we still experience this).
I am bit surprised that RH do not take this one serious enough as it de-facto renders NFSv4 unusable.
Shall I open a case with SEG?
Thanks.

(In reply to comment #10)
> Hi Ian,
> Is there anything I can do to have this fixed asap? This bug is very
> annoying for us as it prevents us from upgrading to the latest kernel. I
> took matter-of-fact that is going to be fixed in 2.6.18-308.5.1.el5 kernels
> (no, we are not using the PAE kernel, but we still experience this).
> I am bit surprised that RH do not take this one serious enough as it
> de-facto renders NFSv4 unusable.
> Shall I open a case with SEG?

I can asure you that I take this seriously but, as I admitted
above, this one slipped through the cracks and I appologize
for that. So now we've lost some time in the process.

But OTOH, to have this pushed out as an update we need (I
believe, since it's not something I do) support to push for 
it to be proposed as an update.

So, if you haven't logged a case with support, then it will
help if you do. Point them to this bug so they can see what's
going on. Your not alone in wanting this updated and I'm keen
to see it pushed out as an update so we should be fine.

Ian

Case 00651762 opened.

I was incorrect. It appears that one of the other sysadmins had fixed one of the links to remove the trailing slash, so please disregard my comment #8 https://bugzilla.redhat.com/show_bug.cgi?id=814418#c8

(In reply to comment #4)
> A kernel that should resolve this problem is available at:
> http://people.redhat.com/~ikent/kernel-2.6.18-308.5.1.el5.bz814418.3
> 
> It includes the patch posted in comment #3.
> Please test this kernel and report back.

Is there anything available for PAE?

We're using the kernels at the link above just fine, but also need
PAE. Word on the street is that it will be at least 30 days before
this (official) bug fixed kernel shows up in repositories.  Stuck!

(In reply to comment #24)
> (In reply to comment #4)
> > A kernel that should resolve this problem is available at:
> > http://people.redhat.com/~ikent/kernel-2.6.18-308.5.1.el5.bz814418.3
> > 
> > It includes the patch posted in comment #3.
> > Please test this kernel and report back.
> 
> Is there anything available for PAE?
> 
> We're using the kernels at the link above just fine, but also need
> PAE. Word on the street is that it will be at least 30 days before
> this (official) bug fixed kernel shows up in repositories.  Stuck!

I've re-built the kernel from comment #4 and copied across
the PAE packages as well this time.

Have a look and let me know if this is what you are after.

*** Bug 825031 has been marked as a duplicate of this bug. ***

[root@nec-em18 ~]# uname -a
Linux nec-em18.rhts.eng.bos.redhat.com 2.6.18-308.4.1.el5 #1 SMP Wed Mar 28 01:54:56 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
[root@nec-em18 ~]# mkdir -p /exports/home && chmod 777 /exports/hom
chmod: cannot access `/exports/hom': No such file or directory
[root@nec-em18 ~]# mkdir -p /exports/home && chmod 777 /exports/home
[root@nec-em18 ~]# cd /exports/home/
[root@nec-em18 home]# mkdir nfs_dir
[root@nec-em18 home]# echo "haha" > nfs_dir/foo.txt
[root@nec-em18 home]# ln -s nfs_dir/ nfs_link1
[root@nec-em18 home]# ln -s nfs_dir nfs_link2
[root@nec-em18 home]# ll
total 16
drwxr-xr-x 2 root root 4096 Jul 23 02:05 nfs_dir
lrwxrwxrwx 1 root root    8 Jul 23 02:05 nfs_link1 -> nfs_dir/
lrwxrwxrwx 1 root root    7 Jul 23 02:05 nfs_link2 -> nfs_dir
[root@nec-em18 home]# 
[root@nec-em18 home]# tail /etc/exports 
/exports/home *(fsid=0,all_squash,rw,sync)
[root@nec-em18 home]# service portmap restart > /dev/null 2>&1
[root@nec-em18 home]# service nfs restart > /dev/null 2>&1
[root@nec-em18 home]# service nfslock restart > /dev/null 2>&1
[root@nec-em18 home]# /sbin/rpc.statd restart > /dev/null 2>&1
[root@nec-em18 home]# 
[root@nec-em18 home]# mount -t nfs4 `hostname`:/ /mnt -vvv
Warning: rpc.idmapd appears not to be running.
         All uids will be mapped to the nobody uid.
mount: pinging: prog 100003 vers 4 prot tcp port 2049
[root@nec-em18 home]# cd /mnt
[root@nec-em18 mnt]# cat nfs_dir/foo.txt 
haha
[root@nec-em18 mnt]# cat nfs_link1/foo.txt 
cat: nfs_link1/foo.txt: Not a directory
[root@nec-em18 mnt]# cat nfs_link2/foo.txt 
haha
[root@nec-em18 mnt]# 
[root@nec-em18 mnt]# 
[root@nec-em18 mnt]# 


[root@nec-em18 ~]# uname -a
Linux nec-em18.rhts.eng.bos.redhat.com 2.6.18-330.el5 #1 SMP Wed Jul 18 11:18:55 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
[root@nec-em18 ~]# ll /exports/home/
total 16
drwxr-xr-x 2 root root 4096 Jul 23 02:05 nfs_dir
lrwxrwxrwx 1 root root    8 Jul 23 02:05 nfs_link1 -> nfs_dir/
lrwxrwxrwx 1 root root    7 Jul 23 02:05 nfs_link2 -> nfs_dir
[root@nec-em18 ~]# tail /etc/exports 
/exports/home *(fsid=0,all_squash,rw,sync)
[root@nec-em18 ~]# service portmap restart > /dev/null 2>&1
[root@nec-em18 ~]# service nfs restart > /dev/null 2>&1
[root@nec-em18 ~]# service nfslock restart > /dev/null 2>&1
[root@nec-em18 ~]# /sbin/rpc.statd restart > /dev/null 2>&1
[root@nec-em18 ~]# mount -t nfs4 `hostname`:/ /mnt -vvv
Warning: rpc.idmapd appears not to be running.
         All uids will be mapped to the nobody uid.
mount: pinging: prog 100003 vers 4 prot tcp port 2049
[root@nec-em18 ~]# cd /mnt/
[root@nec-em18 mnt]# ll
total 16
drwxr-xr-x 2 root root 4096 Jul 23 02:05 nfs_dir
lrwxrwxrwx 1 root root    8 Jul 23 02:05 nfs_link1 -> nfs_dir/
lrwxrwxrwx 1 root root    7 Jul 23 02:05 nfs_link2 -> nfs_dir
[root@nec-em18 mnt]# cat nfs_dir/foo.txt 
haha
[root@nec-em18 mnt]# cat nfs_link1/foo.txt 
haha
[root@nec-em18 mnt]# cat nfs_link2/foo.txt 
haha
[root@nec-em18 mnt]# 
[root@nec-em18 mnt]# 


This bug has been reproduced & verified.

*** Bug 834717 has been marked as a duplicate of this bug. ***

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
If a path followed a symlink that ended with the slash ("/") character, the LOOKUP_DIRECTORY flag could be set earlier than the last path component. This led to an ENOTDIR (Not a directory) error. The LOOKUP_DIRECTORY flag is now propagated only for the last component. For the purpose of possible automounting, the flag is not needed for intermediate path components; the LOOKUP_CONTINUE flag is set in such a case. The ENOTDIR error no longer occurs in this scenario.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0006.html