Project

General

Profile

Bug #4580

Samba 3.0 in 9.2.1.2 prevents ability to store Hyper-V VHD/VHDX files

Added by Ken Alden over 6 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Nice to have
Assignee:
Jakub Klama
Category:
OS
Target version:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

In the previous version of Freenas, where SMB 2.02 was used, we had no problems accessing VHDx or VHD files for our Hyper-V environment.
In 9.2.1-2 release I just tested, with SMB at 3.0, the Windows server 2012 R2 we use with Hyper-V is expecting more from the Freenas server.
The error we would get was "The storage where the virtual hard disk is located does not support virtual hard disk sharing." Similarly, we couldn't
create a new VHD or VHDx file on the CIFS share either. File protections where checked and all looked OK. There is something that Windows is
expecting now that FreeNAS is running with SMB 3.0.

In returning to 9.2, the problem went away.

I wish I could say more but I'm not that well versed with what changes Windows might expect from a Samba 3.0 server, but the Powershell get-smbconnection is
what I was using to show the different Dialect versions in SMB.

It seems very few folks have seen this just yet, and it took me a while to discover that the change in SMB versions would have this impact. If there is anything I
can provide, please let me know, but it's very easy to replicate if you're running a test environment with Hyper-V and W2K12R2 and a FreeNAS server.

History

#1 Updated by Jordan Hubbard over 6 years ago

  • Category set to 57
  • Assignee set to John Hixson
  • Target version set to 72

#2 Updated by Jordan Hubbard over 6 years ago

What happens if you ask Samba4 to use SMB2 (set both min and max to SMB2 in the SMB configuration)?

#3 Updated by Ken Alden over 6 years ago

Not sure. But I plan to bring up another Freenas unit to test this. I suspect it will be FINE, but will update the ticket as soon as I get the other server up. Do you suggest I use a beta release, or 9.2.1-2 release?

While only a guess, I suspect that if W2K12R2 connects with a higher-level SMB/CIFS server, it expects more features and once FreeNAS was offering SMB3.0 support, it expected additional features that weren't there.

#4 Updated by Andrew Johnson over 6 years ago

Note, I had this problem and setting the share's max protocol to "SMB2_02" fixed it. When using merely "SMB2", it still exhibited the issue, but "SMB2_02" worked.

Note, this affects more than just Hyper-V. you can't even mount VHD files on a freenas CIFS share from within Disk Management in Windows if the freenas share uses SMB3.

I believe this is actually an issue that can be fixed on the Microsoft side:
http://support.microsoft.com/kb/2920193
There's a hotfix there for Windows 8, but doesn't appear to be one for Windows 8.1 unfortunately.

#5 Updated by Andrew Johnson over 6 years ago

(This doesn't rule out that there could also be a fix possible on the Samba side, though).

#6 Updated by Ken Alden over 6 years ago

In My case, I'm running Server 2012 R2. (closer to 8.1 than 8.0 I would guess.

The hotfix doesn't address the error I was receiving, which concerned virtual hard disk sharing. I was not able to mount them either.

I guess the question is really for the Windows guys, in that we need to know what SMB 3.0 triggers the client system to expect, and what isn't getting provided. Perhaps someone can find a powershell like the get-smbconnection that would provide the SMB server attributes or services it can provide and we can compare 2.0.2 vs 3.0

The other question other folks might ask is that if you install the latest release of FreeNAS, would you consider that still an improvement over 9.2.0 if you set SMB to use the SMB2_02 flag? Other than eventually using my FreeNAS as a backup domain controller, I don't have enough knowledge to know why I would want/need SMB 3.0 vs 2.0.2

I do plan to create an ISCSI target on my system and have always planned to migrate my VHDs to use iSCSI instead of CIFS, but I hope I can save someone else the headache of hitting this issue as I did.

-Ken

#7 Updated by Andrew Johnson over 6 years ago

Ken -- so the hotfix actually applied for you on Win Server 2k12? If so, it's nice to know that it doesn't actually fix anything.

I couldn't even get it to apply on my system (Windows 8.1).

#8 Updated by Andrew Johnson over 6 years ago

As for whether 9.2.1.2 with max protocol set to 2_02 is an improvement over 9.2.0, looking over the fixes, not all of them are related to CIFS, so presumably you're getting improvements in all those other departments.

I suppose there's the possibility that 9.2.1.2 has made things worse even for SMB2_02, but that's a difficult thing for me to quantify (i'm not a freenas dev). I can say that a few of the CIFS issues with 9.2.1.* I've seen logged here go away when you set SMB2_02. I still run SMB2_02 on production, not only for the VHD fix, but also because one of the CIFS crasher issues logged here seems to only happen on SMB3, and that scares me enough to hold off for now.

#9 Updated by Ken Alden over 6 years ago

I did not apply the patch on my W 2K12 R2 server. (just for the record). It seemed close to what was going on, but not close enough, and it didn't mention 2K12R2, so I stayed away.

BTW, what do I need to do to set SMB2_02 flag? I will bring up 9.2.1-2 again this weekend.

#10 Updated by Andrew Johnson over 6 years ago

To set max protocol, go to Services > CIFS > Server Maximum protocol in the web interface. Then restart CIFS if it's running.

#11 Updated by Andrew Johnson over 6 years ago

Also, I have a feeling the hotfix would have fixed the issue (they just failed to describe all the ways this issue can manifest itself), but it sounds like you're in the same boat as me in that the haven't released an updated hotfix after releasing 2K12 R2 (Win 8.1 in my case).

#12 Updated by John Hixson over 6 years ago

  • Status changed from Unscreened to Resolved

I'm going to mark this resolved as configuring the max protocol to SMB2_02 addresses the issue.

#13 Updated by Andrew Johnson over 6 years ago

Just my 2 cents -
This is actually logged on the Samba side and the ticket is still open. If the Samba team doesn't consider it resolved by using SMB2_02, I'm not sure why freenas should consider it resolved...
https://bugzilla.samba.org/show_bug.cgi?id=10159

By resolving this it implies that if somebody wants to mount ISOs or VHDs from a freenas CIFS share or create VHDs on a freenas CIFS share, they can't use SMB3, including any of the benefits it offers or may offer in the future.

In summary, In my opinion, setting SMB2_02 is more of a workaround than a resolution to this issue.

#14 Updated by Ken Alden over 6 years ago

I agree with Andrew. In the same vein, it would make sense to set the DEFAULT SMB level to SMB2_02 and permit users to change it to SMB3 if they wished. Then it would be OK to mark this resolved. Ultimately, is this a freenas or samba bug -- to me, it's samba, but for some users, they see only FreeNas and how CIFS is provided is transparent.

I am going to enter a note on the Samba bug (10159) to add the fact that HyperV and windows cannot mount VHD files with the current Samba SMB3 behavior.

UPDATE - 7/4/2014 -

I applied the server 2012 R2 hotfix 2920193, but doing the server 2012 R2 rollup (can't remember the KB, but it's called out in the link above) and it does NOT solve the issue. The best I can see is that it identifies the issue about needing resiliency, but it doesn't permit VHDs to be mounted with the SAMBA version is anything other than SMB2_02.

So, the bottom line is, if you want to use CIFS with Hyper-V to store your VHD files, either edit the SMB.conf file or use the GUI to set the max protocol to SMB2_02

#15 Updated by Jordan Hubbard over 6 years ago

  • Target version changed from 72 to 9.3-BETA

#16 Updated by Ken Alden almost 6 years ago

Hi John,

Is there a pretty good feeling that Samba (the project) will have the necessary code for FreeNAS in 9.3 to solve this? I'm seeing this bug reported as "resolved" for the 9.3 release. I might be able to find a PC where I could install 9.3 to test, otherwise I'm sort of game to take my current 9.2.1.7 system and upgrade it to the latest and worst case (assuming it will still be possible,) set SMB back to 2_02 to keep it working. Hyper-V seems to be acting a little differently lately in that it will drop a VHD that had been connected, if nothing is accessing it (such as a system or paging VHD) It's also now barking about wanting SMB 3.X in system manager.

#17 Updated by Ken Alden over 5 years ago

I'm really sad to report that this bug still exists in 9.3-Current. At least with my current CIFS settings it does.

I can CREATE my vhdx file, but when I start the VM, I get the error "Remote SMB share does not support resiliency".

Currently, my CIFS settings have the min at SMB2_02 (I originally had it at ------------) and my MAX is set to SMB3_00.
Should I use different settings?

I know that setting my max to SMB2_02 will allow it to work, as it won't expect resiliency with SMB2, but what we found was that Hyper-V would simply "drop" the VHD connection over time and the drive would disappear from the VM. It's possible that was due to my older 9.2.7 server which was pretty minimally configured vs my test 9.3 server, but I guess we were all hoping that SAMBA 3 would finally solve this issue.

Does anyone know of a corresponding bug # in the Samba forums addressing this issue?

Thanks,
Ken

P.S. Is there anyway to mark this bug no longer as "RESOLVED" (as it isn't)?

P.P.S. I'm pretty sure, MSFT is calling this feature something that is included in the 3.02 Spec of SMB. I don't have the full spec for what they call it, but it's part of server 2012 and 2102 R2, which is what I'm testing against. I couldn't find anywhere on the Samba project, whether or not the current 4.2.0 release of Samba includes support for the full 3.02 spec, but if Freenas 9.3 is using samba 4.2.0, I think we know the answer :-(. Clearly, this isn't a freenas bug, but rather a limitation in the SMB implementation of Samba, and one can only guess from their limited roadmap as to when this part of 3.02 will be included.

#18 Updated by John Hixson over 5 years ago

  • Status changed from Resolved to Screened
  • Target version changed from 9.3-BETA to 49

Ken Alden wrote:

I'm really sad to report that this bug still exists in 9.3-Current. At least with my current CIFS settings it does.

I can CREATE my vhdx file, but when I start the VM, I get the error "Remote SMB share does not support resiliency".

Currently, my CIFS settings have the min at SMB2_02 (I originally had it at ------------) and my MAX is set to SMB3_00.
Should I use different settings?

According to the history of this ticket, SMB2_02 was working (which is why it was resolved). This means, you should try setting your maximum protocol to SMB2_02.

I know that setting my max to SMB2_02 will allow it to work, as it won't expect resiliency with SMB2, but what we found was that Hyper-V would simply "drop" the VHD connection over time and the drive would disappear from the VM. It's possible that was due to my older 9.2.7 server which was pretty minimally configured vs my test 9.3 server, but I guess we were all hoping that SAMBA 3 would finally solve this issue.

Does anyone know of a corresponding bug # in the Samba forums addressing this issue?

I know of none. Perhaps one should be created? I can do that, if you would be willing to chime in. You could create one as well.

Thanks,
Ken

P.S. Is there anyway to mark this bug no longer as "RESOLVED" (as it isn't)?

Yes. I am changing that.

P.P.S. I'm pretty sure, MSFT is calling this feature something that is included in the 3.02 Spec of SMB. I don't have the full spec for what they call it, but it's part of server 2012 and 2102 R2, which is what I'm testing against. I couldn't find anywhere on the Samba project, whether or not the current 4.2.0 release of Samba includes support for the full 3.02 spec, but if Freenas 9.3 is using samba 4.2.0, I think we know the answer :-(. Clearly, this isn't a freenas bug, but rather a limitation in the SMB implementation of Samba, and one can only guess from their limited roadmap as to when this part of 3.02 will be includ

We aren't using samba 4.2.0... yet. We are using 4.1.17. Moving to a new samba version is always a scary thing, especially a big transition like that. It's bitten us before, so we're not going to be so quick to do so again. However, it's on my roadmap, it just needs testing.

#19 Updated by Ken Alden over 5 years ago

Totally agree. However, unless Samba 4.2.0 were to have the full 3.02 spec implemented, I certainly wouldn't be an advocate for making the change, beta or otherwise. I would be curious if Samba 4.2.0 believes they have this implemented...

-Ken

#20 Updated by Jordan Hubbard over 4 years ago

  • Assignee changed from John Hixson to Jakub Klama

#21 Updated by Jakub Klama over 4 years ago

  • Status changed from Screened to Resolved

9.3 is using Samba 4.3.6 now, so I guess it's already solved

#22 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Target version changed from 49 to N/A

Also available in: Atom PDF