* NFS4: ID-mapping Problem with Linux Client and NetApp Server
@ 2012-02-08 14:49 Sven Geggus
2012-02-08 15:33 ` Bryan Schumaker
0 siblings, 1 reply; 5+ messages in thread
From: Sven Geggus @ 2012-02-08 14:49 UTC (permalink / raw)
To: linux-nfs
Hello,
I'm trying to set up a couple of Active-directory integrated Linux machines
using NFS4 volumes on a NetApp Server as storage media.
So far, I'm nearly there, but the final step seems to be missing:
My client (Debian GNU/Linux with nfs-utils 1.2.5) can mount the NetApp
Emulator and Users are managed completely by AD Objects using nslcd.
Now I try to mount the NetApp Emulator vis NFS4 as root:
mount -t nfs4 -o sec=krb5 dataontap-801.<fqdn>:/vol/v_testhome1/testhome1 /mnt/
This also works, however the NetApp is printing some strange warning:
[nfsd.rpc.request.bad:warning]: Client 10.1.7.174 is sending bad rpc requests with error: RPC version mismatch or authentication error(73)
[nfsd.auth.status.bad:warning]: Client 10.1.7.174 has an authentication error 2
This is probably harmless and caused by the local root which does not have a
valid AD account.
After the mount I can successfully browse the volume as user and my machine
is even able to read/write files to/from the server.
However the files are not owned by the correct users. Server is just sending
me invalid stuff.
Here is the owner string I get from the server looking into the packets using
wireshark:
...
recc_attr: FATTR4_OWNER (36)
fattr4_owner: root@<fqdn>
length: 19
contents: root@<fqdn>
fill bytes: opaque data
recc_attr: FATTR4_OWNER_GROUP (37)
fattr4_owner_group: nobody
length: 6
contents: nobody
fill bytes: opaque data
However checking with Windows and SMB these files are not owned by root but
rather by the user which is trying to access the server.
On a Linux machine I would now try to run the server side rpc.idmapd with
verbose options, but unfortunately with NetApp I don't know exactly what to do.
So, any hint what I am missing here?
Client side userid mapping seems to work fine, as I can seen something like
this wehen running rpc.idmapd in verbose mode:
rpc.idmapd: Client 11: (user) name "root@<fqdn>" -> id "0"
rpc.idmapd: Client 11: (group) name "nobody" -> id "65534"
Regards
Sven
--
"A strategy for rewarding artists that regulates 'copies' makes as much sense
in the digital age as a strategy for controlling greenhouse gases that
regulates breathing." (Lawrence Lessig)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: NFS4: ID-mapping Problem with Linux Client and NetApp Server
2012-02-08 14:49 NFS4: ID-mapping Problem with Linux Client and NetApp Server Sven Geggus
@ 2012-02-08 15:33 ` Bryan Schumaker
2012-02-08 16:12 ` Sven Geggus
0 siblings, 1 reply; 5+ messages in thread
From: Bryan Schumaker @ 2012-02-08 15:33 UTC (permalink / raw)
To: Sven Geggus; +Cc: linux-nfs
On 02/08/12 09:49, Sven Geggus wrote:
> Hello,
>
> I'm trying to set up a couple of Active-directory integrated Linux machines
> using NFS4 volumes on a NetApp Server as storage media.
>
> So far, I'm nearly there, but the final step seems to be missing:
>
> My client (Debian GNU/Linux with nfs-utils 1.2.5) can mount the NetApp
> Emulator and Users are managed completely by AD Objects using nslcd.
>
> Now I try to mount the NetApp Emulator vis NFS4 as root:
>
> mount -t nfs4 -o sec=krb5 dataontap-801.<fqdn>:/vol/v_testhome1/testhome1 /mnt/
>
> This also works, however the NetApp is printing some strange warning:
>
> [nfsd.rpc.request.bad:warning]: Client 10.1.7.174 is sending bad rpc requests with error: RPC version mismatch or authentication error(73)
> [nfsd.auth.status.bad:warning]: Client 10.1.7.174 has an authentication error 2
This does look suspicious... using wireshark, can you look at a packet sent by the client to the server. Under "Remote Procedure Call", check that check the "Credentials" have kerberos. Also check the server configuration to make sure that krb5 is allowed and using the DES-CBC-CRC enctype.
>
> This is probably harmless and caused by the local root which does not have a
> valid AD account.
>
> After the mount I can successfully browse the volume as user and my machine
> is even able to read/write files to/from the server.
>
> However the files are not owned by the correct users. Server is just sending
> me invalid stuff.
>
> Here is the owner string I get from the server looking into the packets using
> wireshark:
>
> ...
> recc_attr: FATTR4_OWNER (36)
> fattr4_owner: root@<fqdn>
> length: 19
> contents: root@<fqdn>
> fill bytes: opaque data
> recc_attr: FATTR4_OWNER_GROUP (37)
> fattr4_owner_group: nobody
> length: 6
> contents: nobody
> fill bytes: opaque data
The idmapper usually maps users to "nobody" when they don't exist. My best guess is that your problem has something to do with your kerberos configuration. Is the client in the keytab? I don't know how much of this blog post still applies, but at once point what you're trying to do was possible: http://nfsworld.blogspot.com/2005/06/using-active-directory-as-your-kdc-for.html. It was written about Fedora-based machines, so some of the commands may be different on debian.
>
> However checking with Windows and SMB these files are not owned by root but
> rather by the user which is trying to access the server.
>
> On a Linux machine I would now try to run the server side rpc.idmapd with
> verbose options, but unfortunately with NetApp I don't know exactly what to do.
>
> So, any hint what I am missing here?
>
> Client side userid mapping seems to work fine, as I can seen something like
> this wehen running rpc.idmapd in verbose mode:
>
> rpc.idmapd: Client 11: (user) name "root@<fqdn>" -> id "0"
> rpc.idmapd: Client 11: (group) name "nobody" -> id "65534"
>
> Regards
>
> Sven
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NFS4: ID-mapping Problem with Linux Client and NetApp Server
2012-02-08 15:33 ` Bryan Schumaker
@ 2012-02-08 16:12 ` Sven Geggus
2012-02-08 18:06 ` Bryan Schumaker
0 siblings, 1 reply; 5+ messages in thread
From: Sven Geggus @ 2012-02-08 16:12 UTC (permalink / raw)
To: linux-nfs
Bryan Schumaker schrieb am Mittwoch, den 08. Februar um 16:33 Uhr:
> > [nfsd.rpc.request.bad:warning]: Client 10.1.7.174 is sending bad rpc requests with error: RPC version mismatch or authentication error(73)
> > [nfsd.auth.status.bad:warning]: Client 10.1.7.174 has an authentication error 2
>
> This does look suspicious... using wireshark, can you look at a packet
> sent by the client to the server.
Which one? There are quite a lot (mount only):
78.495261 10.1.7.174 -> 10.1.1.14 TCP ns > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=295718 TSER=0 WS=3
78.495763 10.1.1.14 -> 10.1.7.174 TCP nfs > ns [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=1 TSV=2168684 TSER=295718
78.495776 10.1.7.174 -> 10.1.1.14 TCP ns > nfs [ACK] Seq=1 Ack=1 Win=14600 Len=0 TSV=295718 TSER=2168684
78.495932 10.1.7.174 -> 10.1.1.14 NFS V4 NULL Call
78.496314 10.1.1.14 -> 10.1.7.174 NFS V4 NULL Reply (Call In 193)
78.496326 10.1.7.174 -> 10.1.1.14 TCP ns > nfs [ACK] Seq=45 Ack=29 Win=14600 Len=0 TSV=295718 TSER=2168684
78.499028 10.1.7.174 -> 10.1.1.14 TCP 43936 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=295719 TSER=0 WS=3
78.499352 10.1.1.14 -> 10.1.7.174 TCP nfs > 43936 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=1 TSV=2168684 TSER=295719
78.499673 10.1.7.174 -> 10.1.1.14 TCP 43936 > nfs [ACK] Seq=1 Ack=1 Win=14600 Len=0 TSV=295719 TSER=2168684
78.500604 10.1.7.174 -> 10.1.1.14 NFS V4 NULL Call
78.501116 10.1.1.14 -> 10.1.7.174 TCP nfs > 43936 [ACK] Seq=1 Ack=1421 Win=67160 Len=0 TSV=2168685 TSER=295719
78.513634 10.1.1.14 -> 10.1.7.174 NFS V4 NULL Reply (Call In 199)
78.513642 10.1.7.174 -> 10.1.1.14 TCP 43936 > nfs [ACK] Seq=1421 Ack=229 Win=15672 Len=0 TSV=295722 TSER=2168686
78.516069 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTROOTFH;GETFH;GETATTR
78.516636 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 203) <EMPTY> PUTROOTFH;GETFH;GETATTR
78.517697 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.517905 10.1.7.174 -> 10.1.1.14 NFS V4 NULL Call[Malformed Packet]
78.518127 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 205) <EMPTY> PUTFH;GETATTR
78.518252 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.518378 10.1.1.14 -> 10.1.7.174 NFS V4 NULL Reply (Call In 206)
78.518525 10.1.7.174 -> 10.1.1.14 TCP 43936 > nfs [RST, ACK] Seq=1488 Ack=253 Win=15672 Len=0 TSV=295724 TSER=2168686
78.518844 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 208) <EMPTY> PUTFH;GETATTR
78.518958 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.519388 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 212) <EMPTY> PUTFH;GETATTR
78.519511 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.519904 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 214) <EMPTY> PUTFH;GETATTR
78.520011 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.520436 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 216) <EMPTY> PUTFH;GETATTR
78.521373 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.521945 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 218) <EMPTY> PUTFH;GETATTR
78.522067 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.522564 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 220) <EMPTY> PUTFH;GETATTR
78.522677 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;ACCESS;GETATTR
78.523110 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 222) <EMPTY> PUTFH;ACCESS;GETATTR
78.523210 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
78.523670 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 224) <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
78.523788 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;ACCESS;GETATTR
78.524284 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 226) <EMPTY> PUTFH;ACCESS;GETATTR
78.524457 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
78.528700 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 228) <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
78.528837 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
78.533596 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 230) <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
78.535466 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.536015 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 232) <EMPTY> PUTFH;GETATTR
78.536119 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.536611 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 234) <EMPTY> PUTFH;GETATTR
78.536730 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.537235 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 236) <EMPTY> PUTFH;GETATTR
78.537554 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.538192 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 238) <EMPTY> PUTFH;GETATTR
78.538306 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
78.538781 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 240) <EMPTY> PUTFH;GETATTR
78.538896 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;ACCESS;GETATTR
78.539384 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 242) <EMPTY> PUTFH;ACCESS;GETATTR
78.539491 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
78.539987 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 244) <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
78.577771 10.1.7.174 -> 10.1.1.14 TCP ns > nfs [ACK] Seq=3701 Ack=4177 Win=31752 Len=0 TSV=295739 TSER=2168688
> Under "Remote Procedure Call", check
> that check the "Credentials" have kerberos.
> Also check the server configuration to make sure that krb5 is allowed and
> using the DES-CBC-CRC enctype.
I'm not shure about this. Whatever the Active Directory (2008rc2) default
is, it should apply.
> The idmapper usually maps users to "nobody" when they don't exist. My
> best guess is that your problem has something to do with your kerberos
> configuration. Is the client in the keytab?
How can I check this at the server?
Kerberos stuff looks fine on the client and it already works fine for nss and
ssh. I would rather expect some kind of Missconfiguration concerning
nss/ldap on the server side.
Sven
--
Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch
kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NFS4: ID-mapping Problem with Linux Client and NetApp Server
2012-02-08 16:12 ` Sven Geggus
@ 2012-02-08 18:06 ` Bryan Schumaker
2012-02-09 8:51 ` Sven Geggus
0 siblings, 1 reply; 5+ messages in thread
From: Bryan Schumaker @ 2012-02-08 18:06 UTC (permalink / raw)
To: Sven Geggus; +Cc: linux-nfs
On 02/08/12 11:12, Sven Geggus wrote:
> Bryan Schumaker schrieb am Mittwoch, den 08. Februar um 16:33 Uhr:
>
>>> [nfsd.rpc.request.bad:warning]: Client 10.1.7.174 is sending bad rpc requests with error: RPC version mismatch or authentication error(73)
>>> [nfsd.auth.status.bad:warning]: Client 10.1.7.174 has an authentication error 2
>>
>> This does look suspicious... using wireshark, can you look at a packet
>> sent by the client to the server.
>
> Which one? There are quite a lot (mount only):
Any of the v4 compounds should work. How about "78.524457 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR"?
>
> 78.495261 10.1.7.174 -> 10.1.1.14 TCP ns > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=295718 TSER=0 WS=3
> 78.495763 10.1.1.14 -> 10.1.7.174 TCP nfs > ns [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=1 TSV=2168684 TSER=295718
> 78.495776 10.1.7.174 -> 10.1.1.14 TCP ns > nfs [ACK] Seq=1 Ack=1 Win=14600 Len=0 TSV=295718 TSER=2168684
> 78.495932 10.1.7.174 -> 10.1.1.14 NFS V4 NULL Call
> 78.496314 10.1.1.14 -> 10.1.7.174 NFS V4 NULL Reply (Call In 193)
> 78.496326 10.1.7.174 -> 10.1.1.14 TCP ns > nfs [ACK] Seq=45 Ack=29 Win=14600 Len=0 TSV=295718 TSER=2168684
> 78.499028 10.1.7.174 -> 10.1.1.14 TCP 43936 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=295719 TSER=0 WS=3
> 78.499352 10.1.1.14 -> 10.1.7.174 TCP nfs > 43936 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=1 TSV=2168684 TSER=295719
> 78.499673 10.1.7.174 -> 10.1.1.14 TCP 43936 > nfs [ACK] Seq=1 Ack=1 Win=14600 Len=0 TSV=295719 TSER=2168684
> 78.500604 10.1.7.174 -> 10.1.1.14 NFS V4 NULL Call
> 78.501116 10.1.1.14 -> 10.1.7.174 TCP nfs > 43936 [ACK] Seq=1 Ack=1421 Win=67160 Len=0 TSV=2168685 TSER=295719
> 78.513634 10.1.1.14 -> 10.1.7.174 NFS V4 NULL Reply (Call In 199)
> 78.513642 10.1.7.174 -> 10.1.1.14 TCP 43936 > nfs [ACK] Seq=1421 Ack=229 Win=15672 Len=0 TSV=295722 TSER=2168686
> 78.516069 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTROOTFH;GETFH;GETATTR
> 78.516636 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 203) <EMPTY> PUTROOTFH;GETFH;GETATTR
> 78.517697 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.517905 10.1.7.174 -> 10.1.1.14 NFS V4 NULL Call[Malformed Packet]
> 78.518127 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 205) <EMPTY> PUTFH;GETATTR
> 78.518252 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.518378 10.1.1.14 -> 10.1.7.174 NFS V4 NULL Reply (Call In 206)
> 78.518525 10.1.7.174 -> 10.1.1.14 TCP 43936 > nfs [RST, ACK] Seq=1488 Ack=253 Win=15672 Len=0 TSV=295724 TSER=2168686
> 78.518844 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 208) <EMPTY> PUTFH;GETATTR
> 78.518958 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.519388 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 212) <EMPTY> PUTFH;GETATTR
> 78.519511 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.519904 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 214) <EMPTY> PUTFH;GETATTR
> 78.520011 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.520436 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 216) <EMPTY> PUTFH;GETATTR
> 78.521373 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.521945 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 218) <EMPTY> PUTFH;GETATTR
> 78.522067 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.522564 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 220) <EMPTY> PUTFH;GETATTR
> 78.522677 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;ACCESS;GETATTR
> 78.523110 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 222) <EMPTY> PUTFH;ACCESS;GETATTR
> 78.523210 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
> 78.523670 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 224) <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
> 78.523788 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;ACCESS;GETATTR
> 78.524284 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 226) <EMPTY> PUTFH;ACCESS;GETATTR
> 78.524457 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
> 78.528700 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 228) <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
> 78.528837 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
> 78.533596 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 230) <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
> 78.535466 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.536015 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 232) <EMPTY> PUTFH;GETATTR
> 78.536119 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.536611 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 234) <EMPTY> PUTFH;GETATTR
> 78.536730 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.537235 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 236) <EMPTY> PUTFH;GETATTR
> 78.537554 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.538192 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 238) <EMPTY> PUTFH;GETATTR
> 78.538306 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;GETATTR
> 78.538781 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 240) <EMPTY> PUTFH;GETATTR
> 78.538896 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;ACCESS;GETATTR
> 78.539384 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 242) <EMPTY> PUTFH;ACCESS;GETATTR
> 78.539491 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
> 78.539987 10.1.1.14 -> 10.1.7.174 NFS V4 COMPOUND Reply (Call In 244) <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR
> 78.577771 10.1.7.174 -> 10.1.1.14 TCP ns > nfs [ACK] Seq=3701 Ack=4177 Win=31752 Len=0 TSV=295739 TSER=2168688
>
>> Under "Remote Procedure Call", check
>> that check the "Credentials" have kerberos.
>
>> Also check the server configuration to make sure that krb5 is allowed and
>> using the DES-CBC-CRC enctype.
>
> I'm not shure about this. Whatever the Active Directory (2008rc2) default
> is, it should apply.
I have no idea what their default is, but I'm fairly certain only DES and Triple-DES work against OnTap (somebody correct me if I'm wrong, please).
>
>> The idmapper usually maps users to "nobody" when they don't exist. My
>> best guess is that your problem has something to do with your kerberos
>> configuration. Is the client in the keytab?
>
> How can I check this at the server?
I'm not sure offhand, my best guess is something under vserver -> nfs -> kerberos-config, but I've never set this up on ontap so that might not be right.
- Bryan
>
> Kerberos stuff looks fine on the client and it already works fine for nss and
> ssh. I would rather expect some kind of Missconfiguration concerning
> nss/ldap on the server side.
>
> Sven
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NFS4: ID-mapping Problem with Linux Client and NetApp Server
2012-02-08 18:06 ` Bryan Schumaker
@ 2012-02-09 8:51 ` Sven Geggus
0 siblings, 0 replies; 5+ messages in thread
From: Sven Geggus @ 2012-02-09 8:51 UTC (permalink / raw)
To: linux-nfs
Bryan Schumaker <bjschuma@netapp.com> wrote:
> Any of the v4 compounds should work. How about "78.524457 10.1.7.174 -> 10.1.1.14 NFS V4 COMPOUND Call <EMPTY> PUTFH;LOOKUP;GETFH;GETATTR"?
OK, here is this one:
I skipped IP and TCP headers, starting with RPC:
Internet Protocol, Src: 10.1.7.174 (10.1.7.174), Dst: 10.1.1.14 (10.1.1.14)
Transmission Control Protocol, Src Port: 793 (793), Dst Port: nfs (2049), Seq: 1629, Ack: 1657, Len: 196
Remote Procedure Call, Type:Call XID:0x1496ad4c
Fragment header: Last fragment, 192 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0000 1100 0000 = Fragment Length: 192
XID: 0x1496ad4c (345419084)
Message Type: Call (0)
RPC Version: 2
Program: NFS (100003)
Program Version: 4
Procedure: COMPOUND (1)
Credentials
Flavor: RPCSEC_GSS (6)
Length: 32
GSS Version: 1
GSS Procedure: RPCSEC_GSS_DATA (0)
GSS Sequence Number: 10
GSS Service: rpcsec_gss_svc_none (1)
GSS Context: <DATA>
length: 12
contents: <DATA>
Verifier
Flavor: RPCSEC_GSS (6)
GSS Token: 00000025602306092A864886F71201020201011100FFFFFF...
GSS Token Length: 37
GSS-API Generic Security Service Application Program Interface
OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_blob: 01011100FFFFFFFFA4C9778A70A0DFF48E0AC0599AD935BE
krb5_tok_id: KRB5_GSS_GetMIC (0x0101)
krb5_sgn_alg: HMAC (0x0011)
krb5_snd_seq: A4C9778A70A0DFF4
krb5_sgn_cksum: 8E0AC0599AD935BE
Network File System
[Program Version: 4]
[V4 Procedure: COMPOUND (1)]
Tag: <EMPTY>
length: 0
contents: <EMPTY>
minorversion: 0
Operations (count: 4)
Opcode: PUTFH (22)
filehandle
length: 28
[hash (CRC-32): 0x285d5ed2]
decode type as: unknown
filehandle:
2A04000001000000050000000000042A0100000002000000...
Opcode: LOOKUP (15)
Filename: vol
length: 3
contents: vol
fill bytes: opaque data
Opcode: GETFH (10)
Opcode: GETATTR (9)
GETATTR4args
attr_request
bitmap[0] = 0x0010011a
[5 attributes requested]
mand_attr: FATTR4_TYPE (1)
mand_attr: FATTR4_CHANGE (3)
mand_attr: FATTR4_SIZE (4)
mand_attr: FATTR4_FSID (8)
recc_attr: FATTR4_FILEID (20)
bitmap[1] = 0x0030a23a
[9 attributes requested]
recc_attr: FATTR4_MODE (33)
recc_attr: FATTR4_NUMLINKS (35)
recc_attr: FATTR4_OWNER (36)
recc_attr: FATTR4_OWNER_GROUP (37)
recc_attr: FATTR4_RAWDEV (41)
recc_attr: FATTR4_SPACE_USED (45)
recc_attr: FATTR4_TIME_ACCESS (47)
recc_attr: FATTR4_TIME_METADATA (52)
recc_attr: FATTR4_TIME_MODIFY (53)
Answer:
Internet Protocol, Src: 10.1.1.14 (10.1.1.14), Dst: 10.1.7.174 (10.1.7.174)
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 793 (793), Seq: 1657, Ack: 1825, Len: 300
Remote Procedure Call, Type:Reply XID:0x1496ad4c
Fragment header: Last fragment, 296 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0001 0010 1000 = Fragment Length: 296
XID: 0x1496ad4c (345419084)
Message Type: Reply (1)
[Program: NFS (100003)]
[Program Version: 4]
[Procedure: COMPOUND (1)]
Reply State: accepted (0)
[This is a reply to a request in frame 40]
[Time from request: 0.000489000 seconds]
Verifier
Flavor: RPCSEC_GSS (6)
GSS Token: 00000025602306092A864886F71201020201011100FFFFFF...
GSS Token Length: 37
GSS-API Generic Security Service Application Program Interface
OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_blob: 01011100FFFFFFFF4E710FD04090348728ADC573608BB721
krb5_tok_id: KRB5_GSS_GetMIC (0x0101)
krb5_sgn_alg: HMAC (0x0011)
krb5_snd_seq: 4E710FD040903487
krb5_sgn_cksum: 28ADC573608BB721
Accept State: RPC executed successfully (0)
Network File System
[Program Version: 4]
[V4 Procedure: COMPOUND (1)]
Status: NFS4_OK (0)
Tag: <EMPTY>
length: 0
contents: <EMPTY>
Operations (count: 4)
Opcode: PUTFH (22)
Status: NFS4_OK (0)
Opcode: LOOKUP (15)
Status: NFS4_OK (0)
Opcode: GETFH (10)
Status: NFS4_OK (0)
Filehandle
length: 28
[hash (CRC-32): 0x4cc21d2f]
decode type as: unknown
filehandle:
2B04000001000000050000000000042B0100000002000000...
Opcode: GETATTR (9)
Status: NFS4_OK (0)
GETATTR4res
resok4
obj_attributes
attrmask
bitmap[0] = 0x0010011a
[5 attributes requested]
mand_attr: FATTR4_TYPE (1)
mand_attr: FATTR4_CHANGE (3)
mand_attr: FATTR4_SIZE (4)
mand_attr: FATTR4_FSID (8)
recc_attr: FATTR4_FILEID (20)
bitmap[1] = 0x0030a23a
[9 attributes requested]
recc_attr: FATTR4_MODE (33)
recc_attr: FATTR4_NUMLINKS (35)
recc_attr: FATTR4_OWNER (36)
recc_attr: FATTR4_OWNER_GROUP (37)
recc_attr: FATTR4_RAWDEV (41)
recc_attr: FATTR4_SPACE_USED (45)
recc_attr: FATTR4_TIME_ACCESS (47)
recc_attr: FATTR4_TIME_METADATA (52)
recc_attr: FATTR4_TIME_MODIFY (53)
attr_vals
mand_attr: FATTR4_TYPE (1)
nfs_ftype4: NF4DIR (2)
mand_attr: FATTR4_CHANGE (3)
changeid: 1426762506587602944
mand_attr: FATTR4_SIZE (4)
size: 0
mand_attr: FATTR4_FSID (8)
fattr4_fsid
fsid4.major: 2
fsid4.minor: 0
recc_attr: FATTR4_FILEID (20)
fileid: 1067
recc_attr: FATTR4_MODE (33)
fattr4_mode: 00
000. .... .... .... = Unknown
.... 0... .... .... = not SUID
.... .0.. .... .... = not SGID
.... ..0. .... .... = not save swapped text
.... ...0 .... .... = no Read permission for owner
.... .... 0... .... = no Write permission for owner
.... .... .0.. .... = no Execute permission for owner
.... .... ..0. .... = no Read permission for group
.... .... ...0 .... = no Write permission for group
.... .... .... 0... = no Execute permission for group
.... .... .... .0.. = no Read permission for others
.... .... .... ...0 = no Execute permission for others
recc_attr: FATTR4_NUMLINKS (35)
numlinks: 1
recc_attr: FATTR4_OWNER (36)
fattr4_owner: root@<fqdn>
length: 19
contents: root@<fqdn>
fill bytes: opaque data
recc_attr: FATTR4_OWNER_GROUP (37)
fattr4_owner_group: nobody
length: 6
contents: nobody
fill bytes: opaque data
recc_attr: FATTR4_RAWDEV (41)
specdata1: 0
specdata2: 0
recc_attr: FATTR4_SPACE_USED (45)
space_used: 0
recc_attr: FATTR4_TIME_ACCESS (47)
seconds: 1328776131
nseconds: 359437000
recc_attr: FATTR4_TIME_METADATA (52)
seconds: 1328776131
nseconds: 0
recc_attr: FATTR4_TIME_MODIFY (53)
seconds: 1328776131
nseconds: 0
Sven
--
"A strategy for rewarding artists that regulates 'copies' makes as much sense
in the digital age as a strategy for controlling greenhouse gases that
regulates breathing." (Lawrence Lessig)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-02-09 9:11 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-08 14:49 NFS4: ID-mapping Problem with Linux Client and NetApp Server Sven Geggus
2012-02-08 15:33 ` Bryan Schumaker
2012-02-08 16:12 ` Sven Geggus
2012-02-08 18:06 ` Bryan Schumaker
2012-02-09 8:51 ` Sven Geggus
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.