acl_extended_file() and NFS file systems

acl_extended_file() and NFS file systems

[James Pearson]

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 www.blackhat.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: acl_extended_file() and NFS file systems

[Steve Dickson]

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 www.blackhat.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: acl_extended_file() and NFS file systems

[James Pearson]

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 www.blackhat.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: acl_extended_file() and NFS file systems

[Steve Dickson]

[-- Attachment #1: Type: text/plain, Size: 70 bytes --]

Ok... see if the attached patch takes care of the problem...

SteveD.

[-- Attachment #2: linux-2.4.22-nfs-unavail.patch --]
[-- Type: text/plain, Size: 711 bytes --]

--- 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 */

Re: acl_extended_file() and NFS file systems

[James Pearson]

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 www.blackhat.com
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> 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 www.blackhat.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs