Btrfs (1.8.1) disks are write-protected in Windows 11 22621.963 #546
Comments
|
Added some more diagnostics with the aid of someone fairly well-versed in Btrfs. I have two M.2 NVMe SSDs that are in Btrfs, and both of which I downloaded the games on to. Here are the SSD 1: SSD 2: |
|
I seemed to have fixed the issue, with the help of the same person I talked about in my previous post. However, I will leave the issue open nonetheless. I did SSD 1: Then mounted the drive to /mnt and did a scrub Did the same with SSD 2: Scrub Rebooted into Windows, and tried to run a game that complained of its medium being read-only. Game ran perfectly fine. Proceeded to verify integrity of game files, and all files have successfully validated without issue. I have edited my original post to detail what I have done before the issue started appearing, in an attempt to help you people interested in reproducing the problem. |
|
I've been able to reproduce this on 1.8.1 on a clean virtual disk (64GiB) in a WinPE (1809, 10.0.17763.1) VM, formatted with Specifically I created such a file on NTFS, copied it to the btrfs disk ( |
|
Last log entries (OCRed, didn't have something set up to get logs out of the VM): Edit: |
|
i think this is similar to #468 and #553, and it seems like its caused by running out of disk space while a transaction is happening (such as compressing, transfering, etc). To me it looks like the reported size by windows is not the same as btrf's "working size" (which seems to be smaller, thus causing readonly at ~700-900mb left instead of 0mb), which causes conflict. the best for now is to make sure to have aleast 5gb of headroom at all times, because this is a complex problem. |
As @lesderid points out, the error message is STATUS_INSUFFICIENT_RESOURCES - "resources" here being RAM rather than disk space. My hunch is that something isn't being rolled back cleanly when a function unexpectedly fails due to lack of RAM.
I'd advise this in any case, on both Windows and Linux. |
|
is the problem solved now? |
It still happens on Btrfs 1.9. It happened to me today on Windows 11 22621.4169. I had disabled TPM 2.0 and Secure Boot at the time and still have them disabled. The disk that was write-protected was a partition of an internal hard drive, and the other partitions had no problems writing to or reading from them. The write-protection was added when I was trying to secure delete test files through PeaZip on the very slow preset. All the files were uncompressed as they were compressed archive files. The 3 files appeared to be less than 20K after the secure delete completed with 3 errors. The software writes the files and deletes them one at a time, then moves on to the next file, as I later tested on another disk. These files were over 40K each before the secure delete started. I used the built-in scrub function and got no errors. I tried to use it again later, but got a write-protect error. After restarting Windows, I noticed that one of the files was not affected where it was still over 40K, and another file ended up being 924 mb as claimed by the Btrfs properties tab or 1.07 gb by the general tab. Using a hex editor, I noticed that all the bytes after the number of bytes that Btrfs claimed the file was, but before 1.07 gb, are all 0s. This means that the disk was probably write-protected when this file was written. I tried scrubbing the disk, but I didn't get any errors and it didn't fix the problem. I tried formatting the drive as FAT without checking the quick format to start with a clean drive, but Windows got a blue screen. This seems to be unrelated as I got the same exception before. After restarting Windows, I formatted the disk to NTFS, then deleted the volume to make it raw for a clean format to Btrfs. I added an uncompressed gigabyte test file, then securely deleted it. I added 2 copies of the same file, but with different filenames. I tried to securely delete these 2, but it seems that it only got 1, with the other file being partially securely deleted. The General tab in Properties claimed the file was 947 mb, while the Btrfs tab claimed it was 0 bytes. I used the hex editor to find it filled with all 0s. The disk is write-protected. The files were all uncompressed. This doesn't seem to be entirely related to compressed files, as it happens without them, though it may happen earlier with them. I restarted Windows to find that the 2 files were still there, one corrupted in the same way as the one I checked earlier with the hex editor, but since the Btrfs properties tab now claims 521 mb, less is corrupted. The other is completely unaffected. I scrubbed the disk, but I didn't get any errors, and it didn't fix the corruption problem. |
|
It maybe similar to #694. |
|
Same problem here. |
The issue happened really suddenly while playing video games on Steam with my friends. I downloaded 150 GB worth games over the course of two days, in two separate Windows sessions. Those went through flawlessly. Ran and played those games, all without problems.
Today, upon booting into a new Windows session, games ran fine for the first few hours, and then when my friends and I wanted to play a game which happens to be on the drive where I downloaded those large games on to, I get an error saying that the games could not write to disk, as it is write-protected. Steam however seemed to launch fine when not starting as admin.
Currently, I'm installing a live image of Linux to my USB drive so I can run
btrfs checkMitigations I've tried (will update as I go along):
-Start Steam as Admin - Steam refuses to start, saying disk is write-protected
-Windows SID was inconsistent with registry mappings, I readded correct mappings after getting my Windows user SID, and restarted - issue still persists
My Windows:
-Secure Boot ON (using registry hack to let WinBtrfs run)
-TPM 2.0 ON
Because I also play Valorant and the anticheat requires those be enabled to be compliant on Windows 11.
EDIT: Details of what I was doing before the issue occurred:
You should get a read-only error from there on out
The text was updated successfully, but these errors were encountered: