Bug 10055 - iso mount using native windows 2012 or 8 tools fails due to wrong response to FSCTL_LMR_REQUEST_RESILIENCY
Summary: iso mount using native windows 2012 or 8 tools fails due to wrong response to...
Status: RESOLVED DUPLICATE of bug 10159
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.0.7
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL: http://support.microsoft.com/kb/2920193
Depends on:
Reported: 2013-07-30 07:08 UTC by evli964
Modified: 2014-02-12 21:19 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description evli964 2013-07-30 07:08:06 UTC
When mounting an iso using the built-in tools from windows server 2012 or windows 8 the operation fails. (dialog box 'sorry there was a problem mounting the file)

When setting 'server max protocol = SMB2_02' the mount works perfectly.

When doing a network trace the last operation is a FSCTL_LMR_REQUEST_RESILIENCY,
to which the reply is STATUS_INVALID_DEVICE_REQUEST. According to msdn (http://msdn.microsoft.com/en-us/library/ee380168.aspx) this should be STATUS_NOT_SUPPORTED for protocol versions higher than 2.002

Comment 1 Andrew Bartlett 2013-11-15 19:32:04 UTC
See bug #10159 for an explanation of why this fails. HyperV strictly requires FSCTL_LMR_REQUEST_RESILIENCY when used against SMB 2.10 or higher.  

Almost certainly a HyperV component is in use here.  We are working with Microsoft about the backup case.  We may simply be too late, but I'll alert them to this additional use case.
Comment 2 Andrew Bartlett 2014-02-12 21:19:25 UTC
This much is now fixed on the Microsoft side, please use the hotfix at KB 2920193 for Window 2012 and Windows 8. 

The rest of the issue is confirmed as a duplicate of 10159, which will track any fixes we get from Microsoft for 2012R2, and any change we make in the long term to support this feature.

*** This bug has been marked as a duplicate of bug 10159 ***