- #VERIFYING FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED SOFTWARE#
- #VERIFYING FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED WINDOWS#
Posting is provided "AS IS" with no warranties, and confers no rights. This can be beneficial to other community members reading the thread. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. UPDATE1 12-16-16 - We have had a few customers report this now and we are actively investigating the issue. More to come as we learn more. Yes, the request ID's are unique each time. The first unmount actually performed the work. Some calls report success because they didn't get an error, so for instance back to back unmounts would succeed even though only The unmount was probably issued as a result to the mount failure as a precaution to ensure it is unmounted.
Same errors then I guess someone should open a case to have it investigated. I don't have anything on this error, so can't offer a solution. Interesting, so this appears to be related to some wmi problem - but scratching my head why it only seems to effect the file server workloads you are protecting. NORMAL UnmountStorage: Succeeded for RequestId: 55cabbfd-c94e-4109-b8ac-c7d6a6a24b85", WARNING *** Mojito error was: SMVhdMountError 0 None", WARNING at .(VhdMountInstance instance)", WARNING *** Mojito error was: WMIFailedToExecuteQuery 0 None", WARNING at .(String path", VhdMountMode mode), WARNING at .(ManagementScope managementScope", ManagementObject mObj, String methodName, Object inParams, Boolean throwOnFail) WARNING at .(ManagementScope managementScope", String jobPath, Boolean throwOnFail), WARNING MountStorage: Failed for RequestId: 55cabbfd-c94e-4109-b8ac-c7d6a6a24b85 with exception: .StorageManager.StorageManagerException:įailed to mount vhd: .Wmi.NonFatalWmiException: Job \\DPMSERVER\root\virtualization\v2:Msvm_StorageJob.InstanceID=""B7D3118D-06F3-46E1-918A-1B3575BBAD89"" When I kicked off the failed sync job the request id was different. Are RequestId's different each time DPM wants to mount storage or are they the same per each recovery point, etc? I noticed after the reboot No where in between does it mention a successful mount. I noticed the top states that it can't mount but then at theĮnd of the error it states that it had a successful unmounts. Here is a snippit of what my log showed around the time the mounting error occurred. On a side note, this issue only happens to our file servers. During the scan time, there were no mount/unmounts
#VERIFYING FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED WINDOWS#
We have Windows Defender on both the DPM VM and DPM disk server (Windows Server 2016 Built-in).
This posting is provided "AS IS" with no warranties, and confers no rights.
#VERIFYING FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED SOFTWARE#
I would also suggest checking your anti-virus software and exclude the volume(s) used for the storage pool and see if that helps. You can use this find command to see if you can locate a failure.Ĭ:\Program Files\Microsoft System Center 2016\DPM\DPM\Temp>find /i "vhdcontainer.cs(2" msdpm*.errlog You can look in the msdpm*.errlog files to see if there are any log entries detailing the problem. DPM leverages Hyper-V infrastructure to perform the mounts / dismounts and it sounds like something is going wrong there. Is performed and dismounted when the job is complete. vhdx file is mounted when a new recovery point or consistency check vhdx file stored on the DPM Storage pool volume.
DPM 2016 installed on Windows Server 2016 uses Modern Backup Storage whereby each protected data source is now backed up to a.
0 kommentar(er)
