If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
Windows is hibernating
Dear Windows and Linux newsgroups,
I have a cross platform issue so I am cross posting. Last week I booted two separate Windows 10 computer off a Fedora 29 Xfce Live USB stick. I was able to mount the Windows NTFS main drive, but only as "read only". I could see everything and did (I was not in one of those screw ball hidden Windows partitions), but could not touch anything. After unmounting, I went to clear the dirty flag (from linux), # ntfsfix -d device (/dev/sda1) I got as message as that the dirty flag could not be cleared because "Windows is hibernating". I went back into Windows, made sure the "Fast Boot" option was off (I had been on these machines before) and it was still off. Then I ran a chkdsk c: /f from Windows and rebooted, letting chkdsk run its course. After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Many thanks, -T |
Ads |
#2
|
|||
|
|||
Windows is hibernating
On 09/02/2019 01.57, T wrote:
Dear Windows and Linux newsgroups, I have a cross platform issue so I am cross posting. Last week I booted two separate Windows 10 computer off a Fedora 29 Xfce Live USB stick. I was able to mount the Windows NTFS main drive, but only as "read only".Â* I could see everything and did (I was not in one of those screw ball hidden Windows partitions), but could not touch anything. After unmounting, I went to clear the dirty flag (from linux), Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1) I got as message as that the dirty flag could not be cleared because "Windows is hibernating". I went back into Windows, made sure the "Fast Boot" option was off (I had been on these machines before) and it was still off.Â* Then I ran a Â*Â*Â* chkdsk c: /f from Windows and rebooted, letting chkdsk run its course. After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? When I want to be sure, I tell Windows to reboot, not to poweroff. -- Cheers, Carlos. |
#3
|
|||
|
|||
Windows is hibernating
On 2/8/19 8:46 PM, Carlos E.R. wrote:
What am I doing wrong? When I want to be sure, I tell Windows to reboot, not to poweroff. I used shutdown /r /f /t 00 from the Windows command line at least twice. :'( |
#4
|
|||
|
|||
Windows is hibernating
T wrote:
Dear Windows and Linux newsgroups, I have a cross platform issue so I am cross posting. Last week I booted two separate Windows 10 computer off a Fedora 29 Xfce Live USB stick. I was able to mount the Windows NTFS main drive, but only as "read only". I could see everything and did (I was not in one of those screw ball hidden Windows partitions), but could not touch anything. After unmounting, I went to clear the dirty flag (from linux), # ntfsfix -d device (/dev/sda1) I got as message as that the dirty flag could not be cleared because "Windows is hibernating". I went back into Windows, made sure the "Fast Boot" option was off (I had been on these machines before) and it was still off. Then I ran a chkdsk c: /f from Windows and rebooted, letting chkdsk run its course. After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Many thanks, -T https://askubuntu.com/questions/7028...t-as-read-only "The system might not have the files for writing to NTFS partitions installed. Try this in terminal: sudo apt-get remove ntfsprogs && sudo apt-get install ntfs-3g This removes ntfsprogs if it's present on the system, and installs ntfs-3g which should allow you to write properly to NTFS partitions. Then reboot your system, and attempt to open the NTFS drive for write access. You should now be able to write to the NTFS drive. " Fedora is supposed to have an $MFTMIRR fix. Namely, it ignored MFTMIRR and removed the normal check. Windows 10, when it creates partitions, makes them each with a $MFTMIRR problem. Other Linux distros trip over this. Win7 CHKDSK can fix it (silently, no status message during CHKDSK run). This utility is available on a lot of distros, but is not part of the default install. You'll need to install it. http://disktype.sourceforge.net/ sudo disktype /dev/sdX It might indicate there's some problem. NTFS might not mount if: 1) Hibernation: Windows: powercfg /h off disables both Fast Boot and hibernation to hiberfil.sys 2) NTFS doesn't know how to handle the USN Journal, so it has the option of invalidating it. Such a thing happens if you're in write mode and write something. You can erase the USN Journal while in Windows, although I doubt this would change anything in a positive way. The Search Indexer will need to start indexing all over again, on Windows. 3) The NTFS driver may not know what to do with 4Kn disks. Probably works just fine with 512n and 512e drives. 4) Windows 10 changed cluster size support to 64K. *Don't* use this feature. It ruins compatibility across Windows systems. A Windows 7 OS is not going to know what to do when a 2MB cluster size shows up. Windows 10 uses 4KB clusters for the OS (this became mandatory part way through the releases). At one time, I had Windows 10 on a 64KB cluster partition, and it was running fine, until one day an OS Upgrade came in and said "nuh uh" and I had to change it. You can make data partitions with 64KB clusters, and this will work across OSes. 5) Disks can be set up MBR or GPT. I don't know if there are any issues with partitions on such. I've never seen a problem because of it. fdisk for mbr, gdisk for gpt. 6) Windows 10 uses Reparse Points, with at least three types of Reparse Points, if not more. A Junction Point is the oldest custom NTFS mod. A more recent introduction was a second form of NTFS compression, uses on WinSXS materials or a few files in System32 seem to be using it, even after the compression has been disabled. "Normal" NTFS driver response is "I/O error" when an attempt it made to stat the NTFS files in question. The Linux file manager will refuse to finish painting the directory contents screen on the first "I/O error" file it sees. Lots of these things should not stop mounting in read/write. They can cause problems when accessing various parts of the disk. You can start with "powercfg /h off" then go back to Linux for a look. Next, I'd check whether the packages are set up properly for what you're doing. The partition can't be encrypted, because you probably would not have got as far as you did, if it was. It's not normal for encryption systems to leave filenames exposed. Options would be BitLocker (which can use disk drive encryption if it detects it), TrueCrypt/Veracrypt, or builtin Windows EFS. EFS might leave the filenames visible. In Windows normally, compressed and encrypted files are "colored" in File Explorer. The NTFS new compression might not have a color. Don't know of any other flavors with colored indicators. GetFileAttributes function: FILE_ATTRIBUTE_READONLY = 1 (0x1) FILE_ATTRIBUTE_HIDDEN = 2 (0x2) FILE_ATTRIBUTE_SYSTEM = 4 (0x4) FILE_ATTRIBUTE_DIRECTORY = 16 (0x10) FILE_ATTRIBUTE_ARCHIVE = 32 (0x20) FILE_ATTRIBUTE_NORMAL = 128 (0x80) FILE_ATTRIBUTE_TEMPORARY = 256 (0x100) FILE_ATTRIBUTE_SPARSE_FILE = 512 (0x200) FILE_ATTRIBUTE_REPARSE_POINT = 1024 (0x400) Extended attribute used for "new" compression FILE_ATTRIBUTE_COMPRESSED = 2048 (0x800) Original NTFS compression FILE_ATTRIBUTE_OFFLINE = 4096 (0x1000) FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (0x2000) FILE_ATTRIBUTE_ENCRYPTED = 16384 (0x4000) File attributes can be read with fsutil usn readdata C:\path\to\some\file.ext ******* You can also use the "second opinion" method. Boot up a Ubuntu USB key and check whether you can examine C: from there. You should start with being denied because of $MFTMIRR damage (chkdsk, Win7, to fix) or the perception of being hibernated (powercfg /h off, verify C:\hiberfil.sys is gone). Then Ubuntu should at least allow casual examination of /media/mount/Win10/users/username/Downloads or similar. Fiddling with System32 or WinSXS is less certain. And CHKDSK is a bit of a bear, in that some forms of damage *do not* leave a message on the screen during a run. You examine the "fluffy" options you don't normally use, and switch those on when a partition "seems" to have a problem, but running a repair doesn't seem to be helping. Note that Win7 CHKDSK on a Win10 volume really isn't ideal, but how the hell else are you going to fix MFTMIRR ? It seems Win7 CHKDSK really wasn't backported for Win10 changes, and it *does* mess around with stuff that it should not. But visually, the storage volume still works afterwards. That's the best that I can manage :-/ In an Administrator Command Prompt while in Windows 10 compact /compactOS:query # shows whether "OS wants to compress" compact /compactOS:never # user tells OS to screw off. This allows # at least some of WinSXS or System32 files # to be accessed. I failed today to make # System32 completely visible this way! Paul |
#5
|
|||
|
|||
Windows is hibernating
On 2/8/19 9:06 PM, Paul wrote:
T wrote: Dear Windows and Linux newsgroups, I have a cross platform issue so I am cross posting. Last week I booted two separate Windows 10 computer off a Fedora 29 Xfce Live USB stick. I was able to mount the Windows NTFS main drive, but only as "read only".Â* I could see everything and did (I was not in one of those screw ball hidden Windows partitions), but could not touch anything. After unmounting, I went to clear the dirty flag (from linux), Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1) I got as message as that the dirty flag could not be cleared because "Windows is hibernating". I went back into Windows, made sure the "Fast Boot" option was off (I had been on these machines before) and it was still off.Â* Then I ran a Â*Â*Â* chkdsk c: /f from Windows and rebooted, letting chkdsk run its course. After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Many thanks, -T https://askubuntu.com/questions/7028...t-as-read-only Â*Â* "The system might not have the files for writing to Â*Â*Â* NTFS partitions installed. Â*Â*Â* Try this in terminal: Â*Â*Â*Â*Â*Â* sudo apt-get remove ntfsprogs && sudo apt-get install ntfs-3g Â*Â*Â* This removes ntfsprogs if it's present on the system, and Â*Â*Â* installs ntfs-3g which should allow you to write properly Â*Â*Â* to NTFS partitions. Â*Â*Â* Then reboot your system, and attempt to open the NTFS drive Â*Â*Â* for write access. You should now be able to write to the Â*Â*Â* NTFS drive. Â*Â* " Fedora is supposed to have an $MFTMIRR fix. Namely, it ignored MFTMIRR and removed the normal check. Windows 10, when it creates partitions, makes them each with a $MFTMIRR problem. Other Linux distros trip over this. Win7 CHKDSK can fix it (silently, no status message during CHKDSK run). This utility is available on a lot of distros, but is not part of the default install. You'll need to install it. http://disktype.sourceforge.net/ Â*Â* sudo disktype /dev/sdX It might indicate there's some problem. NTFS might not mount if: 1) Hibernation: Â*Â* Windows:Â* powercfg /h off Â*Â* disables both Fast Boot and hibernation to hiberfil.sys 2) NTFS doesn't know how to handle the USN Journal, so it Â*Â* has the option of invalidating it. Such a thing happens Â*Â* if you're in write mode and write something. You can erase Â*Â* the USN Journal while in Windows, although I doubt this would Â*Â* change anything in a positive way. The Search Indexer will need Â*Â* to start indexing all over again, on Windows. 3) The NTFS driver may not know what to do with 4Kn disks. Â*Â* Probably works just fine with 512n and 512e drives. 4) Windows 10 changed cluster size support to 64K. *Don't* Â*Â* use this feature. It ruins compatibility across Windows systems. Â*Â* A Windows 7 OS is not going to know what to do when a 2MB cluster Â*Â* size shows up. Windows 10 uses 4KB clusters for the OS (this became Â*Â* mandatory part way through the releases). At one time, I had Â*Â* Windows 10 on a 64KB cluster partition, and it was running fine, Â*Â* until one day an OS Upgrade came in and said "nuh uh" and I had Â*Â* to change it. You can make data partitions with 64KB clusters, Â*Â* and this will work across OSes. 5) Disks can be set up MBR or GPT. I don't know if there are any Â*Â* issues with partitions on such. I've never seen a problem because Â*Â* of it. fdisk for mbr, gdisk for gpt. 6) Windows 10 uses Reparse Points, with at least three types of Â*Â* Reparse Points, if not more. A Junction Point is the oldest custom Â*Â* NTFS mod. A more recent introduction was a second form of NTFS Â*Â* compression, uses on WinSXS materials or a few files in System32 Â*Â* seem to be using it, even after the compression has been disabled. Â*Â* "Normal" NTFS driver response is "I/O error" when an attempt it Â*Â* made to stat the NTFS files in question. The Linux file manager Â*Â* will refuse to finish painting the directory contents screen Â*Â* on the first "I/O error" file it sees. Lots of these things should not stop mounting in read/write. They can cause problems when accessing various parts of the disk. You can start with "powercfg /h off" then go back to Linux for a look. Next, I'd check whether the packages are set up properly for what you're doing. The partition can't be encrypted, because you probably would not have got as far as you did, if it was. It's not normal for encryption systems to leave filenames exposed. Options would be BitLocker (which can use disk drive encryption if it detects it), TrueCrypt/Veracrypt, or builtin Windows EFS. EFS might leave the filenames visible. In Windows normally, compressed and encrypted files are "colored" in File Explorer. The NTFS new compression might not have a color. Don't know of any other flavors with colored indicators. GetFileAttributes function: FILE_ATTRIBUTE_READONLY = 1 (0x1) FILE_ATTRIBUTE_HIDDEN = 2 (0x2) FILE_ATTRIBUTE_SYSTEM = 4 (0x4) FILE_ATTRIBUTE_DIRECTORY = 16 (0x10) FILE_ATTRIBUTE_ARCHIVE = 32 (0x20) FILE_ATTRIBUTE_NORMAL = 128 (0x80) FILE_ATTRIBUTE_TEMPORARY = 256 (0x100) FILE_ATTRIBUTE_SPARSE_FILE = 512 (0x200) FILE_ATTRIBUTE_REPARSE_POINT = 1024 (0x400)Â* Extended attribute used for "new" compression FILE_ATTRIBUTE_COMPRESSED = 2048 (0x800)Â*Â*Â*Â* Original NTFS compression FILE_ATTRIBUTE_OFFLINE = 4096 (0x1000) FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (0x2000) FILE_ATTRIBUTE_ENCRYPTED = 16384 (0x4000) File attributes can be read with Â*Â* fsutil usn readdata C:\path\to\some\file.ext ******* You can also use the "second opinion" method. Boot up a Ubuntu USB key and check whether you can examine C: from there. You should start with being denied because of $MFTMIRR damage (chkdsk, Win7, to fix) or the perception of being hibernated (powercfg /h off, verify C:\hiberfil.sys is gone). Then Ubuntu should at least allow casual examination of /media/mount/Win10/users/username/Downloads or similar. Fiddling with System32 or WinSXS is less certain. And CHKDSK is a bit of a bear, in that some forms of damage *do not* leave a message on the screen during a run. You examine the "fluffy" options you don't normally use, and switch those on when a partition "seems" to have a problem, but running a repair doesn't seem to be helping. Note that Win7 CHKDSK on a Win10 volume really isn't ideal, but how the hell else are you going to fix MFTMIRR ? It seems Win7 CHKDSK really wasn't backported for Win10 changes, and it *does* mess around with stuff that it should not. But visually, the storage volume still works afterwards. That's the best that I can manage :-/ In an Administrator Command Prompt while in Windows 10 Â*Â* compact /compactOS:queryÂ*Â*Â*Â*Â*Â*Â*Â*Â* # shows whether "OS wants to compress" Â*Â* compact /compactOS:neverÂ*Â*Â*Â*Â*Â*Â*Â*Â* # user tells OS to screw off. This allows Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* # at least some of WinSXS or System32 files Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* # to be accessed. I failed today to make Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* # System32 completely visible this way! Â*Â*Â* Paul Thank you! |
#6
|
|||
|
|||
Windows is hibernating
On 09/02/2019 04:46, Carlos E.R. wrote:
When I want to be sure, I tell Windows to reboot, not to poweroff. There no such things as reboot in Windows 10 unless you have something like this: [ alt-No ] https://i.imgur.com/YV345Kb.jpg In Windows 10 there is something called "Restart" and everybody should use it once a week. You may not know but the OP (who goes by the name of "T", "Tiger" and "Todd & Margo") is a known Rogue Trader who is always trying to find new ways to defraud customers who are old and very new to computers. -- With over 950 million devices now running Windows 10, customer satisfaction is higher than any previous version of windows. |
#7
|
|||
|
|||
Windows is hibernating
T wrote:
Dear Windows and Linux newsgroups, I have a cross platform issue so I am cross posting. Last week I booted two separate Windows 10 computer off a Fedora 29 Xfce Live USB stick. I was able to mount the Windows NTFS main drive, but only as "read only". I could see everything and did (I was not in one of those screw ball hidden Windows partitions), but could not touch anything. After unmounting, I went to clear the dirty flag (from linux), # ntfsfix -d device (/dev/sda1) I got as message as that the dirty flag could not be cleared because "Windows is hibernating". I went back into Windows, made sure the "Fast Boot" option was off (I had been on these machines before) and it was still off. Then I ran a chkdsk c: /f from Windows and rebooted, letting chkdsk run its course. After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Many thanks, -T I put Fedora-Workstation-Live-x86_64-29-1.2.iso on a USB stick (by direct dd), and when booted, I had no problem clicking on a Win10 volume and it mounted RW as you would expect. I checked /etc/mtab to see the mount arguments. The Win10 volume uses my standard "powercfg /h off" as configuration. Paul |
#8
|
|||
|
|||
Windows is hibernating
On 2/9/19 1:57 AM, T wrote:
Dear Windows and Linux newsgroups, I have a cross platform issue so I am cross posting. Last week I booted two separate Windows 10 computer off a Fedora 29 Xfce Live USB stick. I was able to mount the Windows NTFS main drive, but only as "read only".Â* I could see everything and did (I was not in one of those screw ball hidden Windows partitions), but could not touch anything. After unmounting, I went to clear the dirty flag (from linux), Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1) I got as message as that the dirty flag could not be cleared because "Windows is hibernating". I went back into Windows, made sure the "Fast Boot" option was off (I had been on these machines before) and it was still off.Â* Then I ran a Â*Â*Â* chkdsk c: /f from Windows and rebooted, letting chkdsk run its course. After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Many thanks, -T You have to turn off hibernating completely, run powercfg.exe /hibernate off at an administrator command prompt |
#9
|
|||
|
|||
Windows is hibernating
On 2/9/19 6:04 AM, 😉 Good Guy 😉 wrote:
Thank you for helping me update my killfile. Bye, Bye, forever. :') |
#10
|
|||
|
|||
Windows is hibernating
On 2/9/19 12:22 PM, Carlos E.R. wrote:
On 09/02/2019 16.14, Rich wrote: In comp.os.linux.misc T wrote: After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Are you mounting, in Linux, as ntfs or ntfs-3g? The 'ntfs' Linux driver is read only. The 'ntfs-3g' Linux driver is the read/write driver. But, unless you ask mount to use ntfs-3g specifically, the auto-detected default (at least on the one system I've got where I mount an ntfs formatted USB drive [left as ntfs for compatibility with a winblows system]) is 'ntfs'. Depends on the distribution; for example on openSUSE the default is ntfs-3g. This is the only instance I have not been able to mount an NTFS read/write with Fedora. $ cat /etc/redhat-release Fedora release 29 (Twenty Nine) $ rpm -qa ntfs\* ntfs-3g-2017.3.23-8.fc29.x86_64 ntfsprogs-2017.3.23-8.fc29.x86_64 This is something windows is doing. I am going to try Rich's and Paul's tips next time this happens. |
#11
|
|||
|
|||
Windows is hibernating
On 2/9/19 6:13 AM, Paul wrote:
T wrote: Dear Windows and Linux newsgroups, I have a cross platform issue so I am cross posting. Last week I booted two separate Windows 10 computer off a Fedora 29 Xfce Live USB stick. I was able to mount the Windows NTFS main drive, but only as "read only".Â* I could see everything and did (I was not in one of those screw ball hidden Windows partitions), but could not touch anything. After unmounting, I went to clear the dirty flag (from linux), Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1) I got as message as that the dirty flag could not be cleared because "Windows is hibernating". I went back into Windows, made sure the "Fast Boot" option was off (I had been on these machines before) and it was still off.Â* Then I ran a Â*Â*Â* chkdsk c: /f from Windows and rebooted, letting chkdsk run its course. After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Many thanks, -T I put Fedora-Workstation-Live-x86_64-29-1.2.iso on a USB stick (by direct dd), and when booted, I had no problem clicking on a Win10 volume and it mounted RW as you would expect. I checked /etc/mtab to see the mount arguments. The Win10 volume uses my standard "powercfg /h off" as configuration. Â*Â* Paul Thank you! |
#12
|
|||
|
|||
Windows is hibernating
On 2/9/19 8:26 AM, dillinger wrote:
On 2/9/19 1:57 AM, T wrote: Dear Windows and Linux newsgroups, I have a cross platform issue so I am cross posting. Last week I booted two separate Windows 10 computer off a Fedora 29 Xfce Live USB stick. I was able to mount the Windows NTFS main drive, but only as "read only".Â* I could see everything and did (I was not in one of those screw ball hidden Windows partitions), but could not touch anything. After unmounting, I went to clear the dirty flag (from linux), Â*Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1) I got as message as that the dirty flag could not be cleared because "Windows is hibernating". I went back into Windows, made sure the "Fast Boot" option was off (I had been on these machines before) and it was still off.Â* Then I ran a Â*Â*Â*Â* chkdsk c: /f from Windows and rebooted, letting chkdsk run its course. After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Many thanks, -T You have to turn off hibernating completely, run powercfg.exe /hibernate off at an administrator command prompt Thank you! |
#13
|
|||
|
|||
Windows is hibernating
On 09/02/2019 23.44, T wrote:
On 2/9/19 12:22 PM, Carlos E.R. wrote: On 09/02/2019 16.14, Rich wrote: In comp.os.linux.misc T wrote: After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Are you mounting, in Linux, as ntfs or ntfs-3g? The 'ntfs' Linux driver is read only. The 'ntfs-3g' Linux driver is the read/write driver. But, unless you ask mount to use ntfs-3g specifically, the auto-detected default (at least on the one system I've got where I mount an ntfs formatted USB drive [left as ntfs for compatibility with a winblows system]) is 'ntfs'. Depends on the distribution; for example on openSUSE the default is ntfs-3g. This is the only instance I have not been able to mount an NTFS Â*Â* read/write with Fedora. $ cat /etc/redhat-release Fedora release 29 (Twenty Nine) $ rpm -qa ntfs\* ntfs-3g-2017.3.23-8.fc29.x86_64 ntfsprogs-2017.3.23-8.fc29.x86_64 That doesn't mean much, as the 'ntfs' driver is not an rpm, but part of the kernel. You have to issue "mount" to see how it is really mounted. Maybe it says "fuse", then it is correct. -- Cheers, Carlos. |
#14
|
|||
|
|||
Windows is hibernating
On 2/9/19 6:53 PM, Carlos E.R. wrote:
On 09/02/2019 23.44, T wrote: On 2/9/19 12:22 PM, Carlos E.R. wrote: On 09/02/2019 16.14, Rich wrote: In comp.os.linux.misc T wrote: After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Are you mounting, in Linux, as ntfs or ntfs-3g? The 'ntfs' Linux driver is read only. The 'ntfs-3g' Linux driver is the read/write driver. But, unless you ask mount to use ntfs-3g specifically, the auto-detected default (at least on the one system I've got where I mount an ntfs formatted USB drive [left as ntfs for compatibility with a winblows system]) is 'ntfs'. Depends on the distribution; for example on openSUSE the default is ntfs-3g. This is the only instance I have not been able to mount an NTFS read/write with Fedora. $ cat /etc/redhat-release Fedora release 29 (Twenty Nine) $ rpm -qa ntfs\* ntfs-3g-2017.3.23-8.fc29.x86_64 ntfsprogs-2017.3.23-8.fc29.x86_64 That doesn't mean much, as the 'ntfs' driver is not an rpm, but part of the kernel. You have to issue "mount" to see how it is really mounted. Maybe it says "fuse", then it is correct. # mount -t ntfs /dev/sdc1 /mnt/MyCDs # mount | grep /dev/sdc1 /dev/sdc1 on /mnt/MyCDs type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blks ize=4096) |
#15
|
|||
|
|||
Windows is hibernating
On 10/02/2019 05.54, T wrote:
On 2/9/19 6:53 PM, Carlos E.R. wrote: On 09/02/2019 23.44, T wrote: On 2/9/19 12:22 PM, Carlos E.R. wrote: On 09/02/2019 16.14, Rich wrote: In comp.os.linux.misc T wrote: After shutting Windows back down and rebooting into Linux, I still could not mount the C: drive as read/write. What am I doing wrong? Are you mounting, in Linux, as ntfs or ntfs-3g? The 'ntfs' Linux driver is read only. The 'ntfs-3g' Linux driver is the read/write driver. But, unless you ask mount to use ntfs-3g specifically, the auto-detected default (at least on the one system I've got where I mount an ntfs formatted USB drive [left as ntfs for compatibility with a winblows system]) is 'ntfs'. Depends on the distribution; for example on openSUSE the default is ntfs-3g. This is the only instance I have not been able to mount an NTFS read/write with Fedora. $ cat /etc/redhat-release Fedora release 29 (Twenty Nine) $ rpm -qa ntfs\* ntfs-3g-2017.3.23-8.fc29.x86_64 ntfsprogs-2017.3.23-8.fc29.x86_64 That doesn't mean much, as the 'ntfs' driver is not an rpm, but part of the kernel. You have to issue "mount" to see how it is really mounted. Maybe it says "fuse", then it is correct. # mount -t ntfs /dev/sdc1 /mnt/MyCDs # mount | grep /dev/sdc1 /dev/sdc1 on /mnt/MyCDs type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blks ize=4096) Ok, that is ntfs-3g, mounted read/write apparently. -- Cheers, Carlos. |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|