I have a NetApp Filer 8.2.1 as my server. When I try to mget the files in the shares using smbclient, it shows STATUS_NOT_SUPPORTED error. I have tried the normal file fetching without signing enabled. The max dialect in the smb.conf is SMB2, with SMBv1 it is working.I am able to login and browse the files in SMBv2 dialect also, but not able to do a mget. Please let me know what can be done. My Samba version is 4.1.9.
Can you upload a network trace of the failed attempt? See https://wiki.samba.org/index.php/Capture_Packets on how to do that.
Created attachment 11925 [details] Packet capture for NetApp Using Samba
I'm inclined to say that NetApp just does not follow the MS-SMB2 spec. https://msdn.microsoft.com/en-us/library/cc246557.aspx has FileAllInformation (0x12) as valid info class to request on QUERY_INFORMATION. NetApp replies with NOT_SUPPORTED. I would have thought that this kind of bug was part of the past with SMB2, the NetApp SMB1 implementation is known to support a very narrow subset of the protocol. I could not have imagined that they have continued this practice with SMB2. I'm sure NetApp will tell you that smbclient is not supported and you must choose a client platform that is on their support list.
NetApp knows there is a issue with FILE_ALL_INFO packet with SMBv2. They are saying that the client should not send the FILE_ALL_INFO packet. Is there any workaround so we can change the FILE_ALL_INFO and send something else so that it is compatible with NetApp or any config change that can be done to support it using Samba.
Why should the client not send this? What should the client use instead?
(In reply to Volker Lendecke from comment #5) I am just asking if there is any workaround from Samba side, so that it can be compatible.
Sure, we could make Samba call something else. The problem is -- without access to a NetApp filer we can not test what infolevels NetApp supports, so it would be a guessing game with unknown outcome over various iterations and releases. Does NetApp have a list of infolevels they support?
I'm afraid the NetApp filer is just broken here. Please log a bug with NetApp. We could change smbclient as the info we return could be gotten from other info levels, however in order to do that as Volker says we will need to know what info levels a NetApp files deems worthy enough to support.
Created attachment 11941 [details] Pcap of device connected to netapp filer This packet capture is from a device directly connected to NetApp filer. Is it possible to check the info levels supported by NetApp.
(In reply to anirudhajitani from comment #9) > Pcap of device connected to netapp filer Please capture full packets. All the packets were cut off after a few bytes. For tcpdump, it's -s 0 that does it. Volker
Created attachment 11944 [details] Basic Info Level Pcap
Created attachment 11945 [details] Basic Info Level Pcap
Created attachment 11946 [details] Compresssion Info Pcap
Created attachment 11947 [details] Pipe Info Pcap
Created attachment 11948 [details] Standard Info Pcap
Created attachment 11949 [details] Stream Info Pcap
Please find the attachments of the Pcap of different Info Levels. Look like Netapp supports only Basic Info, Standard Info and Stream Info Levels.
Wow. So you're telling use the NetApp server only supports *3* info levels ? How can they sell this as a viable product. It's a bad joke ?
We have a swift test through which we are checking and swift test supports only these 5 info levels. Out these 5 2 are not supported. I will try to find out out about the other 7 Info Levels.
(In reply to Jeremy Allison from comment #18) > Wow. So you're telling use the NetApp server only supports *3* info levels ? NetApp strictly follows what their supported clients need. Very reasonable business decision as I was told lately. If you have Linux, don't buy NetApp. If you have NetApp, just don't use Linux or go NFS.
Do you have a list of servers that do not support SMBv2 dialect with Samba 4.1.19.
(In reply to anirudhajitani from comment #22) > Do you have a list of servers that do not support SMBv2 dialect with Samba > 4.1.19. No, we don't. If you can get us an official statement from NetApp about supported infolevels, we could adapt Samba. The problem is -- your testing is just a snapshot, tomorrow they might find out that Vista falls out of their support matrix and the one infolevel that only Vista needs might become unsupported again.
InfoLevel FILE_ALL_INFORMATION is a collection of: FILE_BASIC_INFORMATION FILE_STANDARD_INFORMATION FILE_INTERNAL_INFORMATION FILE_EA_INFORMATION FILE_ACCESS_INFORMATION FILE_POSITION_INFORMATION FILE_MODE_INFORMATION FILE_ALLIGNMENT_INFORMATION FILE_NAME_INFORMATION If a SMB2 QUERY_INFO request of InfoType SMB2_0_INFO_FILE and InfoLevel FILE_ALL_INFORMATION returns STATUS_NOT_SUPPORTED, do you think it would it be possible to have the Samba client try each InformatioLevel seperately and use the details returned by successful responses?