MS Services for Unix permission problems

[Tom Buskey]

On 4/27/07, Ric Werme <ewerme at comcast.net> wrote:
>
>
> > > > On Solaris I get this error:
> > > > NFS access failed for server blahblah: error 7 (RPC: Authentication
> > > error)
> > >
> > > This generally indicates that the MOUNT protocol server (part of the
> NFS
> > > server) doesn't like the client for some reason.
>
> Given that you say the mount command succeeded, but ls doesn't, I'm
> not quite sure how you get a RPC error instead of a NFS error, but a
> lot of NFS clients have done a poor job keeping that straight.
>
> > > Permissions on visible from the unix side are 777
>
> so, "ls -ld /sfu" worked?  Please, please, please include the commands
> you use.  Cut and paste from an xterm window works great.


> I have been able to mount it with mount -t nfs SFUserver:/nfs /sfu but I
> get
> > the error on ls -la /sfu.
> > A df shows the right size.
>
> So, "df /sfu" also works?



# tbuskey at bos0it-buskey:/home/tbuskey
$ sudo mount -t nfs  bos0lt-16zmpc1:/nfs /sfu
# tbuskey at bos0it-buskey:/home/tbuskey
$ ls -ald /sfu
drwxrwxrwx 2 tbuskey wheel 64 Apr 27 14:05 /sfu/
# tbuskey at bos0it-buskey:/home/tbuskey
$ ls -al /sfu
ls: reading directory /sfu: Input/output error
total 0
# tbuskey at bos0it-buskey:/home/tbuskey
$ df /sfu
Filesystem            Size  Used Avail Use% Mounted on
bos0lt-16zmpc1:/nfs    56G   15G   41G  27% /sfu



> > > I've run wireshark on the Linux side and see the ACCESS reply is 0x00
> > > (deny all)
>
> Okay, you have to look at the file handles involved.  There ought to have
> been a LOOKUP sometime before the ACCESS.  Hmm, could also be READDIRPLUS.
>
> Let's back up to something simpler.  On Windows, create a small text file
> with notepad, emacs, or some other text-only editor so that it would be


touch x on the windows side

accessed as /sfu/foo from the Unix side of things.
>
> With tcpdump/ethereal/wireshark running, do "ls -l /sfu/foo" from a
> client.
> You should see, scattered among various GETATTRs, a LOOKUP to the server.
> The LOOKUP reply will either have a permission denied NFS (not RPC) error
> or
> attributes for /sfu/foo.  If you get an RPC error, then we have to look at
> RPC stuff that's before the NFS-specific protocol.  You may also see
> ACCESS
> and maybe other calls.  The file handle in the NFS request will identify
> the file being asked about.


I've got SFU only doing NFSv2.
Linux issues a GETATTR then READDIR
SFU replies READDIR with NFSERR_ACCES

Switch SFU to v3 & restart
Linux issues calls: ACCESS, ACCESS, ACCESS
SFU replies ACCESS denied to 3rd call with AUTH_ERROR
 (client must begin new session)



If the ls worked, then try "file /sfu/foo".  That will read the file and
> should say it's random text, you'll see ACCESS and READ calls.
>
> There's a decent chance I'd need to see the traces myself to make full
> sense of them.  Be sure to match up the dialog with the commands.  You
> probably don't want to post them here, I'd prefer a URL for the ASCII or
> binary traces.
>


If the file command works, then I'd try things like "ls -l /sfu",
> "echo Death to PCs > /sfu/bar", and gradually work up to bigger more
> complex operations.
>
>         -Ric Werme
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20070427/6044f668/attachment.html