Has anyone been able to mount a cdot CIFS share in AIX?

[officeworks]

Hi folks,

in 7mode we used to be able to mount CIFS shares directly in AIX with something like.. mount -v cifs.....

we are running clustered data ontap 8.2... but no joy on AIX.. mount -v cifs fails with

There was an error connecting the share or the server.

Make sure the lsdev command shows that device nsmb0 is in

the Available state.  Also make sure that the share name,

user name and password are accurate.

packet traces indicate that the filer is returning Error: STATUS_UNSUCCESSFUL...

Linux servers are quite happy with cdot... mount.cifs "just works" like it did in 7-mode.. this is to the same share with the same credentials!

[officeworks]

For anyone else that is looking... a hunt around the web turned up this thread which mentions AIX and suggests it is related to unicode.. http://the-blue-orb.blogspot.com.au/2011/01/ascii-v-unicode-windows-2008-shares.html                                         

In windows, it was patched so AIX clients could connect.. http://support.microsoft.com/kb/975512

This thread shows similar symptoms http://ask.wireshark.org/questions/24386/nt-status-status_unsuccessful-0xc0000001 and also points to CIFS client not being able to do unicode...

but it mentions this bug which is 'fixed'.. http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=617674

We have the suggested levels of code.. but no luck getting it to work yet..

[officeworks]

add this to the "it used to work in 7dot but it was unsupported and won't work in cdot" list..

IBM say "AIX CIFS follows the SMB1 specification"..

Netapp say.. ""The initial draft of SMB1 was indeed ASCII only. It was later revised to support unicode which is the SMB1 that cDOT supports."

so they both support the spec.. they just won't work with each other and there is no support...ie., DEAD END

[parisi]

Keep in mind that CIFS on AIX was never on the support matrix for 7mode. It worked, but was never qualified or tested. Support for it and Samba was always on a "best effort" basis. Only Mac and Windows CIFS were qualified.

http://support.netapp.com/matrix/

cDOT eliminated non-Unicode CIFS support for all SMB flavors. AIX would need to send CIFS requests in Unicode format to work. This is why Linux CIFS mounts work.

For example, in a packet trace of a Linux CIFS mount:

45    3.800625    10.228.225.140    10.63.3.68    SMB    148    Negotiate Protocol Request

1... .... .... .... = Unicode Strings: Strings are Unicode

46    3.801075    10.63.3.68    10.228.225.140    SMB    159    Negotiate Protocol Response

1... .... .... .... = Unicode Strings: Strings are Unicode

48    3.801209    10.228.225.140    10.63.3.68    SMB    324    Session Setup AndX Request, User: \root

1... .... .... .... = Unicode Strings: Strings are Unicode

49    3.814292    10.63.3.68    10.228.225.140    SMB    200    Session Setup AndX Response

1... .... .... .... = Unicode Strings: Strings are Unicode

AIX sends non-Unicode/ASCII and you'd see this:

333         2.402341              10.61.83.50         10.63.3.68            SMB       203         Session Setup AndX Request,

User: domain\administrator

1. 0... .... .... .... = Unicode Strings: Strings are ASCII

On the cluster, in sktrace, you'd see this:

[kern_sktlogd:info:3069] 11.16.02.021841+0461 [1.0] CIFS_Dbg:nbb2e1c=CheckUnicode: Non-Unicode request not supported. cmd/sub:0x73/0x0<<<<<<

[kern_sktlogd:info:3069] 11.16.02.021847+0663 [1.0] CIFS_Err:nb8a3cb=ConvertInternalErrorToClientError: Client conn cid=55d4f69d at ip 10.61.83.50 getting default error from Res <-- the AIX client

The reason you see so much variance in SMB implementation is that there is no RFC standard for SMB, as Microsoft owns SMB and does not publish RFCs for it. So clients like Samba, AIX, etc get to implement SMB however they like. The fix for your AIX issue would be a patch for AIX that sends Unicode requests for CIFS over SMB1. This variance is the reason NetApp only supports Mac and Windows CIFS clients - it would be virtually impossible to support every CIFS client with all the variance out there.

NFS support spans so many clients because NFS follows RFC standards, so we can predict how the protocol will behave with accuracy.

Hope this helps.

[officeworks]

thanks.. we pretty much reached the same conclusions from out packet traces... but sktrace is new to me and clearly highlights non-unicode is not supported.

I can understand that linux/apple would cover 'most' non windows CIFS clients so non-unicode clients would be quite a small population.. such as embedded devices or things like printers.

Your right about variance in SMB implementation as the CIFS 1.0 RFC was only draft and expired.. for lack of better source.. wikipedia mentions "Microsoft's SMB1 code has to work with a large variety of SMB clients and servers. SMB1 features many versions of information for commands (selecting what structure to return for a particular request) because features such as Unicode support were retro-fitted at a later date. "

Due to this lack of an official standard I tend to agree with "Microsoft's implementations are the de facto CIFS standards" (http://www.ubiqx.org/cifs/Intro.html)... and their implementation DOES allow for non-unicode clients to connect.

So everyone is right.. but it just won't work they way it used to

I already asked IBM about unicode support in their cifs client and they have no plans to add it as they "follow the spec".. and it can connect to a windows file shares.... so it is a dead end for us and we have now headed down the NFS path and battling through username mapping fun

[parisi]

Sounds like a blast!

If you run into any issues, feel free to PM me or post to the communities.

Also, check out TR-4073 for information about LDAP and NFSv4.

http://www.netapp.com/us/media/tr-4073.pdf

Using LDAP with cDOT for your multi-protocol needs will make life infinitely easier, as you don't have to worry about name mapping.