Mount an NTFS partition in write mode

Good morning lol!

I’m a new user of OpenSUSE, I was a Ubuntu user for years.

When I start my OpenSUSE Tumbleweed, at each startup I have a window asking me the root password in order to mount my internal SSD drive Windows partition in read-write access.

How to make this partition mount automatic, please ?

Thanks :shame:

1 Like

Create a proper entry in /etc/fstab.

And of course, you tell; about a window popping up, but fail to tell that you are using a desktop, let alone which one :frowning:

Check here
https://en.opensuse.org/SDB:Mount_additional_disk

I’m on KDE Plasma :slight_smile:

I add the third line to my /etc/fstab :

UUID=c067a06a-cc95-4d0c-9de8-7f948ce4c6c8  /          ext4  defaults  0  1
UUID=EC15-3A13                             /boot/efi  vfat  utf8      0  2
UUID=CC701DFB701DED48                      /ntfs/C    ntfs-3g  defaults  0  0

No mot window popping up, my Windows NTFS partition is mounted at startup, but in read mode, I can’t do anything :cry:

You should not tell things, but show things When you say the file system is mounted read-only then show so"

mount | grep ntfs

also: who is the **I **above in “**I **can’t do anything”. Is that root, is that a normal user?

Remember that NTFS does not have owner:group and permissions from itself. They are all faked. And what is faked is decided by the mount parameters like (from man mount):

uid=value, gid=value and umask=value
Set the file permission on the filesystem. The umask value is given in octal. By default, the files are owned by root and not readable by somebody else.

Show

ls -l /ntfs/C

to see what they are now.

1 Like

Here’s my “fstab” entry:


/dev/disk/by-id/ata-WDC_WD10EZEX-75ZF5A0_WD-WCC1S1730155-part5  /windows/C  ntfs noauto,users,uid=1001,gid=users,fmask=133,dmask=022,locale=en_US.UTF-8  0  0

I’m using device-id rather than UUID, but that does not matter.

The “uid=1001” is the important part. That’s my usual userid when I login. Because of that I am shown as the owner of the NTFS file, and I can write without root access. The “noauto” means that the partition is not automatically mounted at boot – I have to manually mount. So you probably won’t want that “noauto”.

The man pages for mount(8) explain the options used.

That is (of course) all correct, but I think we should not forget that it is still possible that it is mounted ro. E.g. because of earlier usage in a not properly shutdown Windows OS.

Yes, that is another possible issue.

I had it working by disabling fast boot in Windows. But then it stopped working. I had to also disable hibernation in Windows. Turning off fast-boot was not enough.

@hcvv, here are the results of the commands :

niels@rivcrn:~> mount | grep ntfs
/dev/nvme0n1p3 on /ntfs/C type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
niels@rivcrn:~> ls -l /ntfs/C
total 19562316
drwxrwxrwx 1 root root           0 15 févr. 12:00 $Recycle.Bin
drwxrwxrwx 1 root root           0 16 févr. 20:51 $WinREAgent
lrwxrwxrwx 2 root root          13 15 févr. 11:19 Documents and Settings -> /ntfs/C/Users
-rwxrwxrwx 2 root root       12288 17 févr. 21:15 DumpStack.log.tmp
-rwxrwxrwx 1 root root 16927956992 17 févr. 21:50 hiberfil.sys
drwxrwxrwx 1 root root           0 17 févr. 21:15 Intel
drwxrwxrwx 1 root root           0 15 févr. 11:28 OneDriveTemp
-rwxrwxrwx 1 root root  3087007744 17 févr. 21:15 pagefile.sys
drwxrwxrwx 1 root root           0  5 juin   2021 PerfLogs
drwxrwxrwx 1 root root       12288 17 févr. 12:15 ProgramData
drwxrwxrwx 1 root root        8192 17 févr. 12:13 Program Files
drwxrwxrwx 1 root root        4096 16 févr. 21:07 Program Files (x86)
drwxrwxrwx 1 root root           0 15 févr. 11:19 Recovery
-rwxrwxrwx 1 root root    16777216 17 févr. 21:15 swapfile.sys
drwxrwxrwx 1 root root       12288 17 févr. 12:14 System Volume Information
drwxrwxrwx 1 root root        4096 15 févr. 11:42 Users
drwxrwxrwx 1 root root       16384 16 févr. 21:06 Windows

So if I understand well, I can use my own userid by putting it in /etc/fstab, but it’s better to mount it as root. So I should put the “noauto” parameter because it’s annoying to enter the root password at each startup !

Well, not really.

First things first. The options it is mounted with:

(ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

Mind the ro. Thu si t is mounted read-only indeed. Most probably because it was realier used by a Microsoft Windows system and that system is NOT properly and completely shut down. So first back into Windows and then do what @rnickert advises in a post above: no “fast boot” and probably even no “hibernation”

I had it working by disabling fast boot in Windows. But then it stopped working. I had to also disable hibernation in Windows. Turning off fast-boot was not enough.

Then.
The noauto is to avoid mounting it at boot (all entries in /stc/fstab are normally mounted at boot). If you want that depneds on you and the usage you make of this. When it is only scracely, then maybe noauto and mount when needed. Of almost always during a Linux session, then do not use noauto. It is for convenience.

As said, all in /etc/fstab is mounted normally at boot. And that is of course done “as root”, thus no extra entering of a password is needed. You are not asked for other file systems like / and /home to enter a password, aren’t you?

As you see in the ls -l listing, user root and group root are owners of all files here. As I said earlier (and you must have understood that, because you did not ask for further information because you did not understand it), NTFS is NOT Linux, it has NO user and group and file permission bits. THEY ARE ALL FAKED on a Linux system. And root:root is the deafult as the man page tells you. Thus when you do not want everything to be owned by root:root and want to influence protection by permission bits, you must add those as file system dependent options. Thus the example of @rnickert. But again it is up to you to know why you have that NTFS file system mounted and who should be able to meddle there around (and eventually maybe break it :wink: ).

I am sorry to say, but I am afraid that you are not really having the concept of Unix file ownership by user and group and the permissions that belong to it, at you fingertips.