UPDATE: opened gparted, made a check filesystem from there, error showed up, informed me it can't fix it and I should run chkdsk /f from within windows, which I did.
Windows told me there are errors, asked to reboot windows, and during reboot did some fixing. It rebooted again, and then all was ok. From within windows, chkdsk /f no longer showed problems.
But when I entered mint opened the mounted partition and tried to create a folder, it's still read only.
sudo ntfsfix -d /dev/sda3 now says the same exactly as before.
My fstab (I use labels for mounting, as I find it way easier than UUID):
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sdc1 during installation
LABEL=root / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
# /home was on /dev/sdc3 during installation
LABEL=home /home ext4 defaults 0 2
# /usr was on /dev/sdc2 during installation
LABEL=usr /usr ext4 defaults 0 2
/swapfile none swap sw 0 0
LABEL=seagate6TB /mnt/seagate6TB auto nosuid,nodev,nofail,x-gvfs-show 0 0
UUID=F6B9-AD57 /boot/efi vfat umask=0077 0 1
LABEL=win10 /mnt/win10 auto nosuid,nodev,nofail,x-gvfs-show 0 0
the stupid microsoft-infected partition is in the last line
NTFS partitions mount as read-only, not read-write.
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
-
n0body_special
- Level 3
- Posts: 130
- Joined: Sat May 16, 2009 3:00 pm
Re: NTFS partitions mount as read-only, not read-write.
Windows is the world's biggest virus.
UEFI is a Microsoft sponsored boot sector hijacker.
Android is the world's biggest spyware.
But most importantly: Google. Is. Skynet
UEFI is a Microsoft sponsored boot sector hijacker.
Android is the world's biggest spyware.
But most importantly: Google. Is. Skynet
Re: NTFS partitions mount as read-only, not read-write.
We recently had a post in which it didn't work, but how do you fare with manual mounting through
Code: Select all
sudo ntfs-3g -o remove_hiberfile LABEL=win10 /mnt/win10
-
n0body_special
- Level 3
- Posts: 130
- Joined: Sat May 16, 2009 3:00 pm
Re: NTFS partitions mount as read-only, not read-write.
Hey thanks Rene, that worked nicely and was instant! Thanks!
However, LABEL=win10 didn't work with ntfs-3g. It returned an error:
ntfs-3g: Failed to access volume 'LABEL=win10': No such file or directory
I used /dev/sda3 instead, and that did the job. So the command I used was:
sudo ntfs-3g -o remove_hiberfile /dev/sda3 /mnt/win10
It gave no messages, error or otherwise, it just did the job. Thanks again!
(more people should hear about this)
However, LABEL=win10 didn't work with ntfs-3g. It returned an error:
ntfs-3g: Failed to access volume 'LABEL=win10': No such file or directory
I used /dev/sda3 instead, and that did the job. So the command I used was:
sudo ntfs-3g -o remove_hiberfile /dev/sda3 /mnt/win10
It gave no messages, error or otherwise, it just did the job. Thanks again!
(more people should hear about this)
Windows is the world's biggest virus.
UEFI is a Microsoft sponsored boot sector hijacker.
Android is the world's biggest spyware.
But most importantly: Google. Is. Skynet
UEFI is a Microsoft sponsored boot sector hijacker.
Android is the world's biggest spyware.
But most importantly: Google. Is. Skynet
Re: NTFS partitions mount as read-only, not read-write.
Ah, okay, yes, I suppose the LABEL thing actually makes sense. I moreover suppose that now that you mounted it once in that manner that it's also good to go again automatically?
-
n0body_special
- Level 3
- Posts: 130
- Joined: Sat May 16, 2009 3:00 pm
Re: NTFS partitions mount as read-only, not read-write.
yeap. Hiberfile is gone. Filesystem is no longer read-only. Automatically or manually, all is good
Windows is the world's biggest virus.
UEFI is a Microsoft sponsored boot sector hijacker.
Android is the world's biggest spyware.
But most importantly: Google. Is. Skynet
UEFI is a Microsoft sponsored boot sector hijacker.
Android is the world's biggest spyware.
But most importantly: Google. Is. Skynet
Re: NTFS partitions mount as read-only, not read-write.
Good to know, especially after that recent thread in which it did not work. Thanks for reporting.
Re: NTFS partitions mount as read-only, not read-write.
Tacking one more post on to this thread to report a subtle difference from Mint 20.1 to Mint 20.2 with respect to NTFS partitions...
On versions of Mint prior to 20.2, I would expect something like this in /etc/fstab to work:-
UUID=0123456789ABCDEF /media/ntpart ntfs defaults,umask=007,gid=46 0 0
I would also expect that if I either accidentally switched Windows 10 on the same hardware to enable "Fast Start" (or more likely, if a major Windows Update turned it back on for me, without asking permission) then when I came to boot into Mint, the kernel would get upset and not be able to mount the NTFS partition, reporting it to be unavailable (thanks to Windows turning on Fast Start).
However, running Mint 20.2 and having updated to kernel 5.11.0-27, I was seeing similar issues to those reported in this thread - I was able to mount the partition in "read only", but not change it to be write enabled. Even an interactive "sudo chmod" had no effect.
I went back and checked the Windows 10 "Fast Start" settings and, sure enough, it was active. Disabled this and regained the ability to grant write access to the NTFS volumes from Mint.
This is on a brand new dual-boot build on a 2021 LG Gram laptop with 20.2. So it looks like there is new functionality, either in the 5.11 kernel or in 20.2 in general, which will silently force you to "read only" if an NTFS volume is configured for "fast start" and won't give you any clues.
Hopefully this will be useful for someone else...
On versions of Mint prior to 20.2, I would expect something like this in /etc/fstab to work:-
UUID=0123456789ABCDEF /media/ntpart ntfs defaults,umask=007,gid=46 0 0
I would also expect that if I either accidentally switched Windows 10 on the same hardware to enable "Fast Start" (or more likely, if a major Windows Update turned it back on for me, without asking permission) then when I came to boot into Mint, the kernel would get upset and not be able to mount the NTFS partition, reporting it to be unavailable (thanks to Windows turning on Fast Start).
However, running Mint 20.2 and having updated to kernel 5.11.0-27, I was seeing similar issues to those reported in this thread - I was able to mount the partition in "read only", but not change it to be write enabled. Even an interactive "sudo chmod" had no effect.
I went back and checked the Windows 10 "Fast Start" settings and, sure enough, it was active. Disabled this and regained the ability to grant write access to the NTFS volumes from Mint.
This is on a brand new dual-boot build on a 2021 LG Gram laptop with 20.2. So it looks like there is new functionality, either in the 5.11 kernel or in 20.2 in general, which will silently force you to "read only" if an NTFS volume is configured for "fast start" and won't give you any clues.
Hopefully this will be useful for someone else...