Re: rpc.mountd: getfh failed: Operation not permitted

Re: rpc.mountd: getfh failed: Operation not permitted

[Jos van Wezel]

Sorry Steve, your suggestion does not help, at least in our case. All 
mounts via
tcp on nfs server with RH ES3, 2.4.21-15. It is a very annoying issue.

J

> Date: Wed, 02 Feb 2005 09:02:30 -0500
> From: Steve Dickson <SteveD@redhat.com>
> To: "jehan.procaccia" <jehan.procaccia@int-evry.fr>
> CC: nfs@lists.sourceforge.net
> Subject: Re: [NFS] rpc.mountd: getfh failed: Operation not permitted
> 
> 
> 
> jehan.procaccia wrote:
> 
> 
>>Can someone give me a clue about this "getfh" error ?
> 
> 
> Try exporting the filesystem with the 'no_subtree_check'
> option set to see if that helps....
> 
> steved.
> 
> 


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd: getfh failed: Operation not permitted

[Steve Dickson]

Jos van Wezel wrote:

> Sorry Steve, your suggestion does not help, at least in our case. All 
> mounts via
> tcp on nfs server with RH ES3, 2.4.21-15. It is a very annoying issue.

OK.. thanks for trying.... BTW the bz# for this one is 126129

steved.



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

rpc.mountd: getfh failed: Operation not permitted

[jehan.procaccia]

Hello,

Can someone give me a clue about this "getfh" error ?

Feb  1 10:15:06 cobra3 rpc.mountd: getfh failed: Operation not permitted
Feb  1 10:15:06 cobra3 rpc.mountd: authenticated mount request from 
b04-02.int-evry.fr:763 for /p1v3f1/ei0306/test (/p1v3f1)

cobra3 NFS V3 server is running RedHat ES 3 , kernel 2.4.21-27.ELsmp, 
clients are Fedora Core 2 with kernel  2.6.9-1.3_FC2 .
reading this mailing archive I suppect things like:
1) clients are dual boot using dynamic dhcp/dns, so forward ip @ changes 
at every reboots, could this be a ip addressing pb   ?
2) I use automount, I heard about mount points not beeing unmount  as 
they are  ask for a new mount ?
3) getfh is for get file Handle no ?  a lack of file descriptor on the 
NFS server (ulimit)  could be  an issue ?
4) other things ....
Today my only solution is to restart NFS services on the server, until 
getfh problem rises again :-(

Thanks for any advices .


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd: getfh failed: Operation not permitted

[Steve Dickson]

jehan.procaccia wrote:

> Can someone give me a clue about this "getfh" error ?

Try exporting the filesystem with the 'no_subtree_check'
option set to see if that helps....

steved.



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

rpc.mountd: getfh failed: Operation not permitted

[James Pearson]

I have a strange problem with an NFS client that can not mount file
systems from some NFS servers.

e.g.:

mount clark:/disk1 /mnt/tmp
mount: clark:/disk1 failed, reason given by server: Permission denied

The server logs:

Jan 23 12:56:02 clark rpc.mountd: authenticated mount request from
rc0478:623 for /disk1 (/disk1) 
Jan 23 12:56:02 clark rpc.mountd: getfh failed: Operation not permitted 


However, doing:

mount clark:/disk2 /mnt/tmp

works fine - after this mount, /proc/mounts shows:

clark:/disk2 /mnt/tmp nfs
rw,v3,rsize=32768,wsize=32768,hard,udp,lock,addr=clark 0 0


On the server, /disk1 and /disk2 are separate disks exported in exactly
the same way:

/disk1 *(rw)
/disk2 *(rw)


The server is running a 2.4.19 based kernel with nfs-utils v0.3.3
(RedHat 7.2) (all a bit old, but they work fine)

The same client (running a 2.4.23 based kernel) is having the same
problem with a few other servers (but not all). Some of these other
servers are running a 2.4.21 based kernel.

However, every other client (100's of them) has no problems mounting
these same filesystems.

Any ideas?

Thanks

James Pearson


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

rpc.mountd: getfh failed: Operation not permitted

[Marc Schmitt]

Hi (again)

I don't get any rest with my Linux NFS server... after you helped me 
with the mountd RPC issues, today another problem occured, it was the 
third time this happened.

All of a sudden, the server comes into a state where it will fill the 
logs with the error message in the subject. Clients with active mounts 
will continue working fine, but some mount requests (only some!) will be 
denied with that error. Restarting the nfs daemon helps, after that some 
users reported that their homes were hanging with a stale handle, though.

After googling around, I found various suggestions:

- upgrade to kernel >= 2.4.20 (which is something I have to do tonight 
anyway, the server currently suffers from the quota bug in 2.4.18-27 
that was solved in 2.4.20-18, too: "kernel: VFS: find_free_dqentry(): 
Data block full but it shouldn't. kernel: VFS: Error -5 occured while 
creating quota.")

- increase the number of open file handles
Is this really related? file-max is currently set to 399763, which 
should be enough...

- locking issues
Samba is running on the server, too. Could this potentially lead to this 
error? Or serveral clients accessing the same file over NFS?

Hopefully, the problem will go away with the kernel upgrade.

The underlying filesystem is ext3, mounted with usrquota and 
data=journal, btw.

Please let me know if you see other potential reasons for this problem, 
thanks.

Greetings
     Marc





-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd: getfh failed: Operation not permitted

[Marc Schmitt]

Marc Schmitt wrote:

> - upgrade to kernel >= 2.4.20 (which is something I have to do tonight 
> anyway, the server currently suffers from the quota bug in 2.4.18-27 
> that was solved in 2.4.20-18, too: "kernel: VFS: find_free_dqentry(): 
> Data block full but it shouldn't. kernel: VFS: Error -5 occured while 
> creating quota.") 

:(
The upgrade to kernel 2.4.20-19 did not help, today again, I had to 
restart the NFS service due to the "getfh failed: Operation not 
permitted." error.
I've compared the logs (Aug 4th and today). What is interesting is that 
the VFS quota error appeared again today, too. The quota bug occured 
first at 6am and continued happening about once an hour till  11:45am. 
45' later, the first getfh error appears in the logs. Short after that, 
I've restarted the NFS service.

I'd love to help debugging this problem. I'd appreciate some pointers 
where to start, though. How can I provide debugging infos while still 
keeping the machine in production?

What I may try is running vanilla kernel 2.4.22 (once it's out), too, I 
saw that there are improvements for machines with heavy I/O load.

TIA

Regards,

    Marc



-------------------------------------------------------
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=104
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs