From ArchWiki
Latest comment: 10 September 2021 by Dije in topic NTFS full(?) permissions


I added instructions to add users to the disk group when using ntfs-3g-fuseAUR. This was necessary to get access to usb sticks, in general acces to block devices /dev/sd[a-z][1-9, as those are in the disk groups.

Is this good practice, or is there another way to achieve this?

I ask, because Users and groups#Pre-systemd groups lists disk as a group that usually doesn't require users to be added to manually because systemd takes care of it.

—This unsigned comment is by David the goliath (talk) 08:53, 28 May 2017‎. Please sign your posts with ~~~~!

No, it's not a good practice (and never has been) to add normal users to the disk group. If you do this, they have full access to anything stored on any of your disks, including files normally accessible only by root. If you want normal users to be able to mount removable devices, use udisks or some helper - these are safe tools that run with root privileges, either as daemons or with suid. -- Lahwaacz (talk) 12:12, 28 May 2017 (UTC)Reply[reply]
Lahwaacz: Could you please provide some reliable source of information about what are the best practices to allow normal user to be able to mount removable devices? I'm really interested on this, but I'm unable to understand Polkit/Udisks stuff. Excuse me for my lack of intelligence and use Archlinux instead something like Linux Mint or Ubuntu (I don't like them, I'm a difficult person) :( Timofonic (talk) 14:51, 21 July 2017 (UTC)Reply[reply]
Have you read the udisks article? udisks#Mount helpers looks like it will do what you want. What specific step is tripping you up? Try it out and post any issues you have on the forum, the wiki talk pages are mainly for discussing issues with wiki content. Silverhammermba (talk) 21:52, 21 July 2017 (UTC)Reply[reply]


I had really bad experiences resizing partitions under gparted, it broke a Windows 10 system and had to reinstall it. I needed to resize partitions again and was finding desesperately a trustworthy tool.

After reading tons of reviews, I found Easeus Partition Master. Despite the process was quite slow, it got done perfectly.

I did read about Paragon utilities, but I don't trust them because what happened with PTS-DOS (Paragon was founded in Germany by former developers of the PhysTechSoft Russian company, they copied the source code without permission and developed their own fork) plus other bad stuff people say about their products.

Anyone had experienced with resizing partitions of Windows 10 or other versions can tell about the reliability og using GParted? I'm not sure, maybe parted/GParted got patched these days. Timofonic (talk) 14:51, 21 July 2017 (UTC)Reply[reply]

Changing the size without moving the start of the partition is always safe. Moving the start is a bit more tricky, since the Windows bootloader may not like what you are doing. Having an EFI Shell handy is always recommended.
I used GParted with ntfs-3g 2017.3.23 a while ago when migrating from an SSD to another. My EFI booting was quite messed up, but the gist is that Windows was not on the same disk as the EFI partition. I moved the partition to fit a new EFI partition in the old drive, and from what I remember both bootloaders worked. I think it tends to become fully stable once a big OS update happens on Windows 10 as the bootloader gets reconfigured. --Arthur2e5 12:12, 20 June 2020 (UTC)Reply[reply]

NTFS full(?) permissions

The Linux compatible permissions section doesn't mention that the permissions are static; chmod does not actually work on it.

According to JanC(/edited by pizzapants184) on askubuntu, the permissions option can add more.. This might be needed to put (parts) of installations on the harddisk..(like systemd-nspawn stuff or are some of the directories in the linux tree data-heavy,access-infrequent?) That said "defaulty" any windows using that partition might be a security risk. (ugh my security sucks already, really) Jasper1984 (talk) 14:46, 20 January 2018 (UTC)Reply[reply]

Just to add that permissions was all I needed to get full control. Much simpler than all the other recommended solutions. Deserves a mention, IMO. I'm just not confident enough to commit the change myself, in case there's something I'm missing. Dije (talk) 10:00, 10 September 2021 (UTC)Reply[reply]

mount options do not show in /etc/mtab

Something I've just discovered, painfully - ntfs-specific mount options are stripped by the driver and don't make their way into /etc/mtab or mount(8) output. So I was wondering WTH an option I had asked for wasn't active, when in reality it probably was. If you look at the source, options not marked with FLGOPT_APPEND are not passed through.. Might be info worth integrating into main page. Tc424 (talk) 13:39, 3 August 2019 (UTC)Reply[reply]

(Also worth noting that the syslog output does show driver-specific options, so check that. Tc424 (talk) 13:42, 3 August 2019 (UTC))Reply[reply]

Actually, this looks like it might apply to all fuse filesystems? probably relevant. Tc424 (talk) 14:43, 3 August 2019 (UTC)Reply[reply]

The "Deleting Windows hibernate metadata" subsection of the article no longer works

If you have an ntfs partition that was made in Windows and you try to mount it in Linux, you will most likely get a message saying that a hibernation/fast restart file was found and the partition is mounted read-only.

A solution to this is presented in the wiki article stating that one can run a mount command with a -o flag to remove the hibernation file, but it no longer works. Instead one should run a program that comes in the ntfs-3g package called ntfsfix on the partition. That will solve the problem. —This unsigned comment is by Vik (talk) 04:22, 14 August 2020 (UTC). Please sign your posts with ~~~~!Reply[reply]

NTFS damaged vs. mounting as read-only

From history:

"Lahwaacz: revert - the problem is with "damaged NTFS", not "mounting as read-only"; the section already mentions the Windows tool chkdsk and providing detailed step-by-step "guides" for Windows is out of scope"

Yes, after you have solved the problem you will know that it is because of damaged NTFS. When you have the problem, the problem is that the NTFS drive is mounting as read-only.

If you look in the log there will probably be some information directing you in the right direction, but this is not something that the Arch wiki assumes (you looking into the log when problem solving).

When you don't know what the error is, the only way to know that this is a solution is to read through the entire wiki making meaningful headings obsolete.

If you look in the entry below in the wiki, there is a more comprehensive Windows guide on the exact same topic. Yes, I could have understand if you would have linked to that instead with a description of why it is relevant. I have seen many other detailed step-by-step Windows guides in the wiki. Pleae reference to a document saying that relevant Windows guides is out of scope?

I am having a real hard time seeing what the problem with the edit I made is.

—This unsigned comment is by Yogajak328 (talk) 11:48, 9 January 2021‎. Please sign your posts with ~~~~!

The section is solving a problem, not a symptom. -- Lahwaacz (talk) 12:06, 9 January 2021 (UTC)Reply[reply]