Date: Wed, 24 Oct 2001 19:29:21 +0200 From: Paul van der Zwan <paulz@trantor.xs4all.nl> To: Thomas Quinot <quinot@inf.enst.fr> Cc: Paul van der Zwan <paulz@trantor.xs4all.nl>, current@freebsd.org, paulz@trantor.xs4all.nl Subject: Re: Multiple NFS server problems with Solaris 8 clients Message-ID: <200110241729.f9OHTLx21951@trantor.xs4all.nl> In-Reply-To: Message from Thomas Quinot <quinot@inf.enst.fr> of "Fri, 19 Oct 2001 18:31:02 %2B0200." <20011019183102.A20555@cosette.enst.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20011019183102.A20555@cosette.enst.fr>, Thomas Quinot wrote: >Le 2001-10-14, Paul van der Zwan =E9crivait : > >> I am using -current box as a homedir server for my Solaris clients and= >> have noticed a wierd problem. > >Other problems here, with Solaris 2.[68] as clients, and -CURRENT of >yesterday as server. ls works, but ls -l issues a 'NFS getacl failed' >message *and* waits for a timeout once for each file in the directory. > >The server is not multi-homed, and a packet capture shows no trace of >address mismatch problems. One interesting thing is that the client >first does GETATTR on the file (and apparently gets a reply), and >then sends some other RPC, to which the server never replies. >Could this be the getacl request mentioned in the client error message? >I see no mention of getacl whatsoever in the -CURRENT server code. If >no such function is implemented, shouldn't we reject the request? > >A packet capture is available at > http://www.infres.enst.fr/~quinot/nfs.cap > >Client is 137.194.192.1, server is 137.194.162.11. The test consists >in first performing an 'ls' on one file, then an 'ls -l' on the same >file. Result: > >ls photos-ta; ls -l photos-ta >photos-ta >NFS getacl failed for server shalmaneser.enst.fr: error 5 (RPC: Timed >out) >-rw------- 1 quinot astre 474 Oct 18 14:17 photos-ta I have looked at a trace I made using snoop and it shows an NFS_ACL call = which is not supported by FreeBSD. It should have sent a reply that it does not= know the NFS_ACL protocol but apparently it does not. = The only return traffic I see is an empty packet with the tcp ACK. It looks like an implementation error in the -current NFS server. Paul -- = Paul van der Zwan paulz @ trantor.xs4all.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110241729.f9OHTLx21951>