0

I know there are a ton of similar threads but I've tried most of the suggestions and still haven't solved this. I have an NTFS drive which has WinXP on it but I've not booted to it in ages and since building a new system and installing 17.10 on a fresh drive, haven't even got this drive recognised as bootable in grub. When I first installed the system it was fine: I edited FSTAB to mount it in a specific place with certain permissions and it was fine. Current FSTAB entry is:

UUID=8E3CDEC53CDEA80B   /media/SamsungA ntfs-3g defaults,locale=en_US.UTF-8,user,uid=1000,gid=1000,umask=0000   0   0

Right click, properties, permissions: owner: me. access: rw. group: me, access: rw. others: rw. (I think that's 777?). BUT: all folders have padlock icons in thunar and trying to chown files/folders to 775 or 777 per instructions gives "file system mounted as read only" in terminal.

I suspect therefore the problem's in FSTAB? I previously had:

UUID=8E3CDEC53CDEA80B   /media/SamsungA ntfs-3g defaults,locale=en_US.UTF-8,async,big_writes    0   0

Though since I changed to the first entry (in order to speed up access time I believe) it WAS working fine, until some point recently.

Full disclosure, I dual boot to windows 10, but on a different partition (or the same drive as I boot to for linux, neither of which is the problem NTFS drive). Could the win10 install have changed fastboot settings? I've seen reference to this but it all appears to relate to the booting windows drive, which this isn't.

Thanks in advance!

p.s. ntfs-3g installed. ntfs config tool installed & enabled for this drive & the win10 booter. I tried a umount/mount suggestion but it didn't work, and am I right in thinking I should solve this in fstab so it mounts properly on boot rather than once in the file system?

  • 1
    You probably shouldn't try for 777, since making files executable is likely undesired, and it gives full access to everyone. What happens when you add rw to the comma-separated options list in /etc/fstab? – Chai T. Rex Dec 9 '17 at 5:02
  • Thanks. I've not tried this as it seems to be mounted as rw for all users; the windows fix did the job surprsingly, then I added bigwrites to fstab to solve that issue. Cheers. – dez93_2000 Dec 9 '17 at 22:56
3

One possible cause:

The file system is marked as dirty; meaning that it was removed from a system that was hibernated (windows fast start is a hibernation). If the drive was not connected to the system when it was unhibernated the dirty flag wouldn't be removed.

Windows will self-repair some minor issues such as this. Be sure Windows' Fast Start is turned off, some updates will turn it on. Boot Windows 10 twice with the drive connected. Then eject the drive before shutting down Windows.

  • thanks. I turned fast start off and rebooted to windows then xubuntu and that fixed it - surprised but I guess fast start tags all drives. – dez93_2000 Dec 9 '17 at 22:55
  • 1
    yes, hibenation keeps an image of all drives, and write cache in memory. This is why writing to a drive hibernated in anther system can cause corruption. – ravery Dec 10 '17 at 2:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.