Hello, I am posting an answer to a question I asked of this list several days ago. I am trying to include enough keywords describing my problem in the hopes that anyone having the same problem will find this and save themselves weeks of debugging effort.
I am using linux samba smbclient and/or linux-cifs mount.cifs to connect to a NetApp filer. AFAIK my problems have nothing to do with Samba version (within the 3.X series) or NetApp filer version (within the 7.X series). Our network uses Microsoft Active Directory for authentication. For the purposes of the examples below, my AD username is my_username, my AD domain is my_domain.my_company.com. The server 'the_server' happened to be in some other domain 'other_domain', but that appears to be irrelevent. When I try a simple 'smbclient' command: smbclient -U my_domain.my_company.com/my_username%mypassword //the_server/some_share I get an error message: session setup failed: NT_STATUS_MORE_PROCESSING_REQUIRED did you forget to run kinit? If I increase the debugging level of smbclient (-d 10), I get some other interesting messages towards the end: spnego_parse_auth_response failed at 1 Failed to parse auth response SPNEGO login failed: Invalid parameter At this point, any sane person would run off investigating kerberos authentication and SPNEGO, then start fiddling with NTLMv2 vs NTLMv1 and SMB signed versus unsigned authentication tokens. Also, this person would try all possible combinations of command line options to smbclient, trying to explicitly specify IP addresses and different workgroups/domains, combinations of upper/lower case spellings and perhaps dig into strange character sets. Also, there would be some MicroSoft fileserver nearby, and smbclient would work with it JUST FINE(!!!) with nearly all permutations of smbclient commands. Next, you would contact NetApp support. They would claim CIFS compliance and tell you to use a CIFS client. So, you research linux-cifs and the mount.cifs command. linux-cifs is integrated into the linux kernel, but its codebase and capabilities aren't really different from Samba...they are effectively siblings....debugging mount.cifs is just a lot harder. Next, you might get your local NetApp filer admin to turn on debugging on the server. The server admin would tell you they were seeing messages like this: auth.trace.spnegoAuthentication.statusMsg:info]: AUTH: SPNEGO- Could not unpack NTLMSSP Authenticate token The fact that NTLMSSP authentication tokens weren't being parsed properly would lead you to believe that there must be something wrong with how Samba<->NetApp perceive certain authentication mechanisms should be implemented. Obviously either Samba or NetApp isn't following some (undocumented) standard. Here you will remain for the next few weeks, pouring over network traces pulling out your hair and cursing anyone with the word 'support' in their job title for their ineptitude. Alas, you may be lucky enough to try running smbclient this way: smbclient -U my_domain/my_username%mypassword //the_server/some_share The mere removal of my_company.com from the 'domain' specification will cause NetApp to cooperate at all levels. Even mount.cifs will work just fine. Apparently, the NetApp filer doesn't like the 'extended' full domain my_domain.my_company.com, and will only parse the short my_domain properly. This is OK, but during the debugging process where you tried to connect to a Microsoft fileserver and my_domain.my_company.com worked just fine, you believed that NetApp should accept the extended domain too. Also, you may have been lucky enough to have someone in support to point you to NetApp's bugs 50610 and 57032: http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=50610 http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=57032 Of course, you need a now.netapp.com account to see those bugs, and unless you have one because you bought some NetApp products or someone lent you their account, you cannot see that. Those bug reports apply to the MSWindows 'net use' command, and unless you were really smart (I am not), you wouldn't realize exactly how they applied to the Linux SAMBA smbclient command. (And, NetApp support would not have found this bug easily either, because it is filed under Microsoft networking, and you are using Linux Samba). So, I hope that this post is found by people who need it out on the internet, and the world becomes a better place.
