NFS4: ID-mapping Problem with Linux Client and NetApp Server
Subsystems (2)
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 datarecc_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
Signature · 4 lines
"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
Quoted 10 lines · Sven Geggus
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.
Quoted 8 lines
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.
Quoted 13 lines
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:
Quoted 11 lines
...
recc_attr:FATTR4_OWNER(36)
fattr4_owner: root@<fqdn>
length: 19
contents: root@<fqdn>
fill bytes: opaque datarecc_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.
Quoted 19 lines
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
Bryan Schumaker schrieb am Mittwoch, den 08. Februar um 16:33 Uhr:
Quoted 5 lines
Quoted 2 lines
[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
Quoted 5 lines
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.
Quoted 3 lines
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
Signature · 4 lines
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
Quoted 9 lines · Sven Geggus
Bryan Schumaker schrieb am Mittwoch, den 08. Februar um 16:33 Uhr:
Quoted 5 lines
Quoted 2 lines
[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"?
Quoted 59 lines
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
Quoted 8 lines
Quoted 5 lines
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).
Quoted 6 lines
Quoted 4 lines
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
Quoted 8 lines
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
Quoted 1 line · Bryan Schumaker
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: 0Sven
Signature · 4 lines
"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