-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xStorage - Cannot perform the requested operation when the drive is read only #85
Comments
Hi @tenletters10 - thanks for submitting this. Sorry I haven't had a chance to look at this yet. I notice the AllocationUnitSize is 64k - is this a very large disk that is being created/partitioned? |
No worries. The disks are a decent size. I was trying on a various set of sizes (1TB, 2TB, 4TB). |
I can confirm I am seeing the exact same behavior. Adding 3 drives and 3 mountpoints, using xdisk and xmountpoint within foreach loops. xdisk adds the first drive and fails on the second, leaving it raw state and how the exact error stated above. When I manually get through the drives and move onto the mountpoints those work perfect. I then downgraded to 2.6, and xdisk adds the drives perfect, but obviously fails on xmountpoint as that was not part of 2.6. Current work around is script resource instead of xdisk and still load 2.9 so I can utilize the xmountpoint resource. |
Hi @jdillon-wayfair . Thanks for the info! Ill get onto this tonight and hopefully have a solution for you. Are you able to apply the config in verbose mode and upload the output logs here? |
Here is the code snippet followed by the verbose output followed by the screenshot of the drives after the run: |
Hi @jdillon-wayfair - I've been looking into this a bit over the weekend and I think the problem may already possibly be fixed in the latest (not yet released) version of xStorage. A new version of this resource should be being released next week (v3.0.0.0) that contains some fixes that may resolve this. Are you able to wait till this new release comes out? If not, feel free to try the Dev branch version in this repo. Note: this next version will require changes to your config as it does contain a breaking change (see #81) |
That works, as our current work around is a script resource essentially doing similar. |
A pleasure to help. Hopefully the new version will be released to master/PS Gallery soon. Are we able to close this issue? |
Update, 3.1 and 3.0 xstorage still has this issue. In fact 3.1 and 3.0 xstorage now breaks xdiskaccesspath for mounting mountpoints stating, "PartitionNumber, The Argument is null". This is with making the change form DiskNumber to DiskID as requested by the Breaking Change release notes |
Hi @jdillon-wayfair - thanks for the update. Are you able to paste a copy of the log output with the PartitionNumber, The Argument is null error so I can try and track the location? Also, could you put the config in here too? Is this a disk with multiple partitions/volumes or a single partition/volume disk? |
Here is the config:`Configuration testxdisk
}` |
And here is the Null Error:
|
Thanks @jdillon-wayfair - that didn't quite provide what I'd hoped. What I was wanting to see was the Verbose log output so that I could track the code path through the resource. Is there any chance you could run this with the verbose log output enabled? E.g. using something like this?
It will then provide lots more detail as to what code is being called. |
VERBOSE: [testserver]: LCM: [ Start Resource ] [[xWaitForDisk]WaitforDisk_0] VERBOSE: [testserver]: LCM: [ End Set ] [[xDisk]Disk_1] in 0.3750 seconds. VERBOSE: [testserver]: LCM: [ Start Resource ] [[File]SQLFolder_0] VERBOSE: [testserver]: LCM: [ Start Resource ] [[xDiskAccessPath]DiskaccessPath_0] VERBOSE: [testserver]: LCM: [ End Set ] VERBOSE: Operation 'Invoke CimMethod' complete. |
Thanks @jdillon-wayfair - sorry about taking so long. I'll go through this tomorrow night after work and see if I can figure out exactly what is going on here. Thanks again for your patience and assistance! |
Hi,
The verbose output is: LCM: [ Start Resource ] [[xWaitForDisk]Disk1] |
Hi @oribesser - this should be resolved once I can get this PR through: #126 Just needs merge conflicts resolved and it should be able to be merged. |
I have a pull request up for this issue #183 |
When attempting to use 2.9.0.0 I keep getting volumes left in a "raw" volumes with assigned driver letters state even when specifying FSFormat. In the logs I am getting the following errors:
VERBOSE: [localhost]: [[xDisk]Edrive_xDISK] Set-TargetResource: Creat
ing partition on disk number '2' with drive letter 'E' using all free space.
VERBOSE: [localhost]: [[xDisk]Edrive_xDISK] Set-TargetResource: Forma
tting the volume as 'NTFS'.
Cannot perform the requested operation when the drive is read only
+ CategoryInfo : NotSpecified: (StorageWMI:) [], CimException
+ FullyQualifiedErrorId : StorageWMI 43006,Format-Volume
+ PSComputerName : localhost
VERBOSE: [ocalhost]: LCM: [ End Set ] [[xDisk]Edrive_xDISK] in 2.4240 seconds.
The PowerShell DSC resource '[xDisk]Edrive_xDISK' with SourceInfo
'C:\Users\myprofile\Desktop\TestDSC\SSRSDSC.ps1::71::9::xDisk' threw one or more non-terminating
errors while running the Set-TargetResource functionality. These errors are logged to the ETW
channel called Microsoft-Windows-DSC/Operational. Refer to this channel for more details.
+ CategoryInfo : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : NonTerminatingErrorFromProvider
+ PSComputerName : localhost
Below is an example of the config I am using when getting this error:
I can say that if I keep going back and deleting the volume and running the dsc config it will eventually get a correct NTFS volume, but takes about 3 to 5 times before it won't be in a broken state with a "raw" volume. I have also looked at the disk and confirm they are not in read only. Assuming something in the dsc resource is temporarily putting the disk into a read only mode, but as soon as the config is complete and bombs out the disk is not in read only mode.
If I drop back down to my previous version I was using successfully (2.6.0.0), this problem does not exist.
The text was updated successfully, but these errors were encountered: