We've just come across a problem with running 'ls -l' on NFS mounted
files from a client running Fedora Core 1 with the latest coreutils RPM
(5.0-34.1)
Running ls -l on a file exported by a RedHat 7.2 system gives
% ls -l /some/remote/file
ls: /some/remote/file: Input/output error
-rw-rw-r-- 1 james user 17373 Jun 1 20:02 /some/remote/file
/var/log/messages on the client gives:
Jun 23 16:00:53 wingnut kernel: call_verify: server accept status: 1
Jun 23 16:00:53 wingnut last message repeated 2 times
Jun 23 16:00:53 wingnut kernel: RPC: garbage, exit EIO
I've tracked this down to the use of acl_extended_file() by this version
of ls - it works OK on local file systems and NFS file systems exported
by other FC1 machines and Solaris boxes, but gives this error on file
systems exported by RedHat 7.2 and Irix boxes.
I can reproduce the errors with a simple bit of 'C':
#include <sys/types.h>
#include <acl/libacl.h>
#include <errno.h>
main(int argc, char **argv)
{
int ret;
errno = 0;
ret = acl_extended_file (argv[1]);
printf("ret = %d\nerrno = %d\n", ret, errno);
exit (0);
}
(need to link with -lacl)
I've searched around and come across references to a 'noacl' option to
mount that might help, but mount on Fedora doesn't seem to support this
- I get:
unknown nfs mount option: noacl
I don't really know if this a real problem (I can easily fix 'ls' by
backing out the patch to coreutils that introduces this issue), but I
would like to understand more on what is going on ...
Thanks
James Pearson
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
James Pearson wrote:
> We've just come across a problem with running 'ls -l' on NFS mounted
> files from a client running Fedora Core 1 with the latest coreutils
> RPM (5.0-34.1)
>
> Running ls -l on a file exported by a RedHat 7.2 system gives
>
> % ls -l /some/remote/file
> ls: /some/remote/file: Input/output error
> -rw-rw-r-- 1 james user 17373 Jun 1 20:02 /some/remote/file
hmm... it sound like 7.2 is returning garbage but to which
over-the-wire operation? Since FC1 does not have ACL support so
the getxattr() (that is done by your test program) should
be returned EOPNOTSUPP (as it does in my testing) but instead
it sounds like the FC1 is actually trying to send something otw..
Would it be possible to get a strace and ethereal trace of this
phenomenon?
SteveD.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
I've put the strace and ethereal outputs at:
ftp://ftp.moving-picture.com/private/nfs/
The files 'works' from using a file on a FC1 server
The files 'fails' from using a file on a RH7.2 server
Note: it also fails on NFS files from an Irix 6.5.X server
James Pearson
Steve Dickson wrote:
> James Pearson wrote:
>
>> We've just come across a problem with running 'ls -l' on NFS mounted
>> files from a client running Fedora Core 1 with the latest coreutils
>> RPM (5.0-34.1)
>>
>> Running ls -l on a file exported by a RedHat 7.2 system gives
>>
>> % ls -l /some/remote/file
>> ls: /some/remote/file: Input/output error
>> -rw-rw-r-- 1 james user 17373 Jun 1 20:02 /some/remote/file
>
>
> hmm... it sound like 7.2 is returning garbage but to which
> over-the-wire operation? Since FC1 does not have ACL support so
> the getxattr() (that is done by your test program) should
> be returned EOPNOTSUPP (as it does in my testing) but instead
> it sounds like the FC1 is actually trying to send something otw..
> Would it be possible to get a strace and ethereal trace of this
> phenomenon?
>
> SteveD.
>
>
>
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
--- linux-2.4.22/net/sunrpc/clnt.c.org 2004-06-24 10:49:57.000000000 -0400
+++ linux-2.4.22/net/sunrpc/clnt.c 2004-06-24 10:57:59.000000000 -0400
@@ -923,6 +923,16 @@ call_verify(struct rpc_task *task)
return p;
case RPC_GARBAGE_ARGS:
break; /* retry */
+ case RPC_PROG_UNAVAIL:
+ /* report requested program number*/
+ dprintk(KERN_WARNING "RPC: unknown program\n");
+ rpc_exit(task, -ENOSYS);
+ return NULL;
+ case RPC_PROC_UNAVAIL:
+ /* report requested program and procedure number, version */
+ dprintk(KERN_WARNING "RPC: unknown procedure\n");
+ rpc_exit(task, -ENOSYS);
+ return NULL;
default:
printk(KERN_WARNING "call_verify: server accept status: %x\n", n);
/* Also retry */
I think I've worked out what is going on ... when I said the client was
a FC1 box, I didn't give all the facts - it's using a kernel based on
the FC1 kernel - actually one from ATrpms (http://atrpms.net/).
It turns out that this kernel has a 'nfsacl' patch (from
http://acl.bestbits.at/download.html) applied that
adds CONFIG_NFS_ACL (and CONFIG_NFSD_ACL) which are enabled by default -
compiling a new kernel with the CONFIG_NFS_ACL option disabled (i.e.
something closer to a vanilla FC1 kernel), then the problem goes away ...
James Pearson
James Pearson wrote:
> I've put the strace and ethereal outputs at:
>
> ftp://ftp.moving-picture.com/private/nfs/
>
> The files 'works' from using a file on a FC1 server
>
> The files 'fails' from using a file on a RH7.2 server
>
> Note: it also fails on NFS files from an Irix 6.5.X server
>
> James Pearson
>
> Steve Dickson wrote:
>
>> James Pearson wrote:
>>
>>> We've just come across a problem with running 'ls -l' on NFS mounted
>>> files from a client running Fedora Core 1 with the latest coreutils
>>> RPM (5.0-34.1)
>>>
>>> Running ls -l on a file exported by a RedHat 7.2 system gives
>>>
>>> % ls -l /some/remote/file
>>> ls: /some/remote/file: Input/output error
>>> -rw-rw-r-- 1 james user 17373 Jun 1 20:02 /some/remote/file
>>
>>
>>
>> hmm... it sound like 7.2 is returning garbage but to which
>> over-the-wire operation? Since FC1 does not have ACL support so
>> the getxattr() (that is done by your test program) should
>> be returned EOPNOTSUPP (as it does in my testing) but instead
>> it sounds like the FC1 is actually trying to send something otw..
>> Would it be possible to get a strace and ethereal trace of this
>> phenomenon?
>>
>> SteveD.
>>
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
> self defense, top technical experts, no vendor pitches, unmatched
> networking opportunities. Visit http://www.blackhat.com
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
>
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs