MS Services for Unix permission problems

[Ric Werme]

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

The trace you sent separately has only three ACCESS calls, all failed.
It would have been nice to see the whole dialog to compare calls that
worked with those that didn't.

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

Without a trace, I have no comment other than don't bother with V2.
It would be interesting if it worked, but there is little reason to use
V2.  I don't know enough about V4 to be very helpful.

> 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)

You must have remounted, right?

Ethereal says about the first ACCESS call in your trace (the other two are
essentially identical):

      1 15:51:11.806138 146.58.49.13          146.58.49.215         NFS      
V3 ACCESS Call (Reply In 2), FH:0x5ab2a646

Frame 1 (202 bytes on wire, 202 bytes captured)
Ethernet II, Src: Dell_a1:7a:85 (00:11:43:a1:7a:85), Dst: 00:18:8b:bd:3d:b3 
(00:18:8b:bd:3d:b3)
Internet Protocol, Src: 146.58.49.13 (146.58.49.13), Dst: 146.58.49.215 
(146.58.49.215)
Transmission Control Protocol, Src Port: 1017 (1017), Dst Port: nfs (2049), 
Seq: 0, Ack: 0, Len: 148
Remote Procedure Call, Type:Call XID:0x00929acc
    Fragment header: Last fragment, 144 bytes
    XID: 0x929acc (9607884)
    Message Type: Call (0)
    RPC Version: 2
    Program: NFS (100003)
    Program Version: 3
    Procedure: ACCESS (4)
    The reply to this request is in frame 2
    Credentials
    Verifier
Network File System, ACCESS Call FH:0x5ab2a646

No.     Time            Source                Destination           Protocol 
Info
      2 15:51:11.806346 146.58.49.215         146.58.49.13          NFS      
V3 ACCESS Reply (Call In 1)

Frame 2 (78 bytes on wire, 78 bytes captured)
Ethernet II, Src: 00:18:8b:bd:3d:b3 (00:18:8b:bd:3d:b3), Dst: Dell_a1:7a:85 
(00:11:43:a1:7a:85)
Internet Protocol, Src: 146.58.49.215 (146.58.49.215), Dst: 146.58.49.13 
(146.58.49.13)
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 1017 (1017), 
Seq: 0, Ack: 148, Len: 24
Remote Procedure Call, Type:Reply XID:0x00929acc
    Fragment header: Last fragment, 20 bytes
    XID: 0x929acc (9607884)
    Message Type: Reply (1)
    Program: NFS (100003)
    Program Version: 3
    Procedure: ACCESS (4)
    Reply State: denied (1)
    This is a reply to a request in frame 1
    Time from request: 0.000208000 seconds
    Reject State: AUTH_ERROR (1)
    Auth State: client must begin new session (2)

Frame 2 is the reply.  "Reply State: denied (1)" is indeed a RPC-level
rejection.  These normally do not occur.  The complaint, "Auth State: client
must begin new session (2)" may be quite misleading,
http://www.ietf.org/rfc/rfc1831.txt says:

         AUTH_REJECTEDCRED = 2,  /* client must begin new session    */

The "CRED", i.e. credentials, from the request are reasonable.  I didn't
include them above, but the request has:

    Credentials
        Flavor: AUTH_UNIX (1)
        Length: 64
        Stamp: 0x001fee68
        Machine Name: bos0it-buskey
        UID: 6882
        GID: 10
        Auxiliary GIDs
            GID: 10
            GID: 103
            GID: 104
            GID: 105
            GID: 156
            GID: 505
            GID: 55500

The UID/GID stuff shouldn't be rejected by RPC, it should just
be passed to NFS.  "Stamp: 0x001fee68" might be bogus, I think that should
be the Unix time, but the server may ignore it.  I'm not sure what to make
of the "client must begin new session" comment, I'd expect that to only
be used if AUTH_KERB was in use.

SFU's NFS support came from a vendor whose name I forget, but it was at
a time before NFS over TCP was common.  You might try using NFS over UDP.
Beyond that, time for Google, Microsoft Support, or someone who knows
more about Windows and SFU than I do.  Or Samba.

	-Ric Werme