Dolphin cannot mount NTFS partition Solution

Support
,
1

Hello,
I’m sharing here a solution to an issue found after a fresh install of the OpenMandriva ROME 25.06.

Requirements:

I have Searched the forum for my issue and found nothing related or helpful
I have checked the Resources category (Resources Index)
I have reviewed the Wiki for relevant information
I have read the the Release Notes and Errata

OpenMandriva Lx version: ROME 25.06

Desktop environment (KDE, LXQT…): KDE Plasma 6.3.4, KDE Frameworks 6.13.0, Dolphin 25.04.0

Kernel version: 6.14.2-desktop-3omv2590 (64-bit)

Description of the issue (screenshots if relevant):

After a fresh install of OpenMandriva ROME, when trying to mount an NTFS partition from Dolphin, I receive the The requested operation has failed: Error mounting /dev/sda6: wrong fs type, bad option, bad superblock on /dev/sda6, missing codepage or helper program, or other error red message.

Tha same NTFS partition (we can name it DATA) can be mounted with the sudo mount /dev/sda6 /media/user/DATA and then Dolphin can load in read-only the NTFS folders. Dolphin cannot umount this device and a sudo umount /media/user/DATA is required.

Relevant informations (hardware involved, software version, logs or output…):

I found a solution that involves the system configuration.
This is happening because there is only a /etc/udisks2/udisks2.conf in the /etc/udisks2 folder, and there is no /etc/udisks2/mount_options.conf.
Here below the steps I’ve done.

cd /etc/usidks2
sudo cp mount_options.conf.example mount_options.conf
sudo editor mount_options.conf

At this point uncommented the ntfs lines in the [default] section:

### Simple global overrides
[defaults]
# common options, applied to any filesystem, always merged with specific filesystem type options
defaults=rw
allow=exec,noexec,nodev,nosuid,atime,noatime,nodiratime,ro,rw,sync,dirsync,noload

### Specific filesystem type options
# vfat_defaults=uid=$UID,gid=$GID,shortname=mixed,utf8=1,showexec,flush
# vfat_allow=uid=$UID,gid=$GID,flush,utf8,shortname,umask,dmask,fmask,codepage,iocharset,usefree,showexec
ntfs_defaults=uid=$UID,gid=$GID,windows_names
ntfs_allow=uid=$UID,gid=$GID,umask,dmask,fmask,locale,norecover,ignore_case,windows_names,compression,nocompression,big_writes

# 'ntfs' signature, definitions for the legacy ntfs kernel driver and the ntfs-3g fuse driver
ntfs:ntfs_defaults=uid=$UID,gid=$GID,windows_names
ntfs:ntfs_allow=uid=$UID,gid=$GID,umask,dmask,fmask,locale,norecover,ignore_case,windows_names,compression,nocompression,big_writes

# 'ntfs' signature, the new 'ntfs3' kernel driver
ntfs:ntfs3_defaults=uid=$UID,gid=$GID
ntfs:ntfs3_allow=uid=$UID,gid=$GID,umask,dmask,fmask,iocharset,discard,nodiscard,sparse,nosparse,hidden,nohidden,sys_immutable,nosys_immutable,showmeta,noshowmeta,prealloc,noprealloc,hide_dot_files,nohide_dot_files,windows_names,nocase,case

# define order of filesystem driver priorities for the actual mount call,
# required definition for non-matching driver names
ntfs_drivers=ntfs3,ntfs

Now Dolphin is able to mount the NTFS partitions by clicking the voice in the left sidebar.

Note: I found this comment very useful.

Hope this can help someone that it’s facing this issue. Especially for the new OpenMandriva users.

2 Likes
2

@svavs Thanks for reporting.

I wish someone could explain why I can mount and unmount a ntfs partition in Dolphin and some people can not? And yes this is with the default files and settings. I created a text file and can open it from Dolphin, ect.

$ rpm -qa | grep ntfs
lib64ntfs-3g-2022.10.3-1.znver1
ntfsprogs-2022.10.3-1.znver1

$ rpm -qa | grep dolphin
plasma6-dolphin-plugins-25.04.0-1.znver1
lib64dolphinvcs6-25.04.0-2.znver1
lib64dolphinprivate6-25.04.0-2.znver1
plasma6-dolphin-25.04.0-2.znver1

Plasma 6.3.4 and KF 6.13.0

My computer is multi-boot but all systems are OMLx. I wonder if this could be related to where or with what the ntfs partition was created?

It is somewhere between difficult and impossible to fix a bug if we can not determine the cause. Otherwise we are left with “It should work” or “It works for me”, which in my case it does.

This is speculation: A thought would be that people seeing this problem may need to run the Windows chkdsk on that partition. There something in Linux called ntfsfix but I am not sure it works as thoroughly as chkdsk in Windows. I think ntfsfix works like this:

$ sudo ntfsfix /dev/nvme0n1p12
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/nvme0n1p12 was processed successfully.

ntfsfix --help will show how to use and some options you can use with this utility.

A way someone might be able to find out more as to why some people see this problem is if you see this problem with Dolphin then run journalctl -b and look for the time you tried to mount the partition in Dolphin and see what the journal logs say. Or better run journalctl -b > journal-b.txt and post the file created (journal-b.txt) in your forum post or bug report.

This is something that keeps coming up from time to time and just am trying to better understand why? Why it works for some and not others?

3

The problem is usually the UID and GID being initially assigned to the NTFS partition by a different distro. If the partition was created in another distro the UID will be 1000 so the user in OM will not be able to access it.

2 Likes
4

Have you tried

Sudo chown -R $user path-to-disk

5

Hi all,

thank you for your replies.

@LeeTalbert the NTFS partition was created with a different linux distro (I suppose a Debian or Ubuntu), but can still be mounted in a GNOME environment with other distros, Debian based or not. The only thing I have to do in some system like in recent Ubuntu is to toggle the automount option from GNOME Disdks for the NTFS partition: after this, I can mount in rw with the UI.

@pastorczo13 Initially I have not, because the /media/silvano/DATA should be automatically created when mounting the partition in Dolphin and I don’t want the partition to be mounted on boot. When I manually created the DATA folder to mount the partition I’ve done a non-recursive chown: the partition must be able to be mounted in other distros that are using the same username with the same GID and UID (I always use systems in multiboot).

One more detail: there is no line dedicated to this partition in the /etc/fstab and ideally there shoudn’t be (I’m fine with mounting the partition on demand like an external unit).

This issue is very strange: when mounting in Dolphin the NTFS partition containing the Windows OS, I have no error messages and Dolphin always mounts the unit in rw (not when defaults=ro).

Today this solution seems not to be working anymore. Or better, it mounts in ro, but not in rw. I have the error appearing again in Dolphin now.
I’ve changed nothing since yesterday, only shutdown and powered on this morning.

If I changge the defaults=rw into defaults=ro, then Dolphin can correctly mount the partition, but obviously I cannot create files and folders in all mounted units.

I’m glad if I can solve this issue and help others, also because I recently decided to adopt OM as my default distro.

ntfs_dolphin_20250627
ntfs_dolphin_20250627579×250 17.2 KB

6

Citazione
the partition must be able to be mounted in other distros that are using the same username with the same GID and UID (I always use systems in multiboot).

I’m sorry, this is not true. I noticed that some files have UID=1000 in the partition, but OMa assigns UID=1001 to the user.
Doing an ls -la /media/silvano/DATA, some folders have GID=lusers and UID=1000.
And now I cannot do a sudo chown -R $user since now I can only mount the unit in ro.

7

How to set user ID to 1000 instead of 1001

Maybe that would help?

1 Like
8

Each distro that lets the user mount the partition successfully is using UID=1000 as the default first user created, so it looks like your user is the owner.

9

The only reason to continue to do this, is if you have an external drive and are dual booting. There is no need to create a NTFS partition in a Linux distro. Always do that in Windows. The biggest reason I see to do this is games, especially Steam. This is also not a good idea because cloud storage and save files may not work correctly between Proton and native versions of certain games. There are very few exceptions where the Proton version outperforms the native one.

Before you try any user and group changes to your file system, back it up to another media.

If you are trying to share files on your network with a Windows PC and do not want to deal with SAMBA, you can use SFTP/SSH now (since Windows 10, it’s a feature):

Regarding the UID/GID differences, the better practice is to back up your ~ directory and restore sensible dot files. You will not, and should not, need to restore them all.

10

The ntfs partition that I created yesterday will not mount in Dolphin today and I am getting the same error as @svavs. So I can reproduce the problem. This is what journalctl -b shows:

Jun 28 13:00:48 3756-xfs kernel: ntfs3: Enabled Linux POSIX ACLs support
Jun 28 13:00:48 3756-xfs kernel: ntfs3: Read-only LZX/Xpress compression included
Jun 28 13:00:48 3756-xfs kernel: ntfs3(nvme0n1p12): It is recommened to use chkdsk.
Jun 28 13:00:48 3756-xfs kernel: ntfs3(nvme0n1p12): volume is dirty and "force" flag is not set!
Jun 28 13:00:52 3756-xfs dolphin[87104]: QLayout::removeWidget: Cannot remove a null widget.
Jun 28 13:01:08 3756-xfs kernel: ntfs3(nvme0n1p12): It is recommened to use chkdsk.
Jun 28 13:01:08 3756-xfs kernel: ntfs3(nvme0n1p12): volume is dirty and "force" flag is not set!
Jun 28 13:01:13 3756-xfs kwin_x11[3480]: kwin_core: XCB error: 152 (BadDamage), sequence: 45247, resource id: 22703124, major code: 132 (DAMAGE), minor code: 2 (Destroy)
Jun 28 13:01:13 3756-xfs kwin_x11[3480]: kwin_core: XCB error: 3 (BadWindow), sequence: 45248, resource id: 113246273, major code: 147 (SHAPE), minor code: 6 (Input)

I now believe this is a bug and needs a bug report. I do not use ntfs myself and any bug report will need to be filed by someone that uses that.

My belief is that users should not need to install any additional software to open ntfs partition in Dolphin. I am thinking of the many poor unfortunate souls coming from the Windows thing or wishing to dual boot with Windows.

Edit: Yes I can mount the partition with sudo mount -t ntfs /dev/nvme0n1p12 /mnt so I doubt any additional software is needed. I think this is likely a Dolphin bug. And my memory says this has been “fixed” before a few times.

11

This is an internal disk dedicated to data storage shared with the Windows OS and other two linux distros (and not for gaming). The OSs in multiboot resides in the primary disk unit. Never had similar issues. The only break was due to the fast boot enabled in windows and an ntfsfix or a chkdsk E: /f in windows solved everything.

Update
(@WilsonPhillips )
I tried to add the ntfs dedicated line in the /etc/fstab, and the error in Dolphin is not appearing anymore but the filesystem is exclusively mounted in ro mode (with or withouth the /etc/udisks2/mount_options.config). Still root cannot create files and directories.

/dev/sda6 on /media/user/DATA type ntfs (ro,nosuid,nodev,relatime,uid=1001,gid=1007,dmask=0000,fmask=0000,iocharset=utf8,x-gvfs-show)

I tried both

UUID=BAE2A2BEE2A27DEF                       /media/user/DATA         ntfs    rw,nosuid,nodev,uid=1001,gid=1007,nofail,x-gvfs-show,umask=000 0 0

and

UUID=BAE2A2BEE2A27DEF                       /media/user/DATA         ntfs    nosuid,nodev,uid=1001,gid=1007,nofail,x-gvfs-show,umask=000 0 0

Here I fixed the UID and GID to be the ones of the OM system.

12

Maybe there is something broken somewhere. It may be the need to run chkdsk in Windows but I do not and am not going to have Windows so I can not do this.

I am done with testing this, it is apparently useless if one does not have Windows. People with Windows dual booting with OMLx need to sort this.

13

Should that be ntfs3 not ntfs? That is what an OM dev told me. I don’t know, I seem to have confused things more than helped…

14

Hi @ben79 ,

I already boot windows and done a chkdsk from there. Are you meaning you want some one to be able to reproduce this issue on other machines?

15

No what want is for someone that knows enough to fix the issue to listen to you. You have definitely reproduced the issue and provided good information. For that you are due thanks.

16

A warning note: I have seen one or 2 people on the 'net saying that ntfsfix can cause data loss. I am skeptical of this but thought I should mention it.

Something to try:

$ sudo ntfsfix -d /media/user/DATA

From:

$ ntfsfix --help
ntfsfix v2022.10.3 (libntfs-3g)

Usage: ntfsfix [options] device
    Attempt to fix an NTFS partition.

    -b, --clear-bad-sectors Clear the bad sector list
    -d, --clear-dirty       Clear the volume dirty flag
    -h, --help              Display this help
    -n, --no-action         Do not write anything
    -V, --version           Display version information

For example: ntfsfix /dev/hda6

Developers' email address: ntfs-3g-devel@lists.sf.net
News, support and information:  https://github.com/tuxera/ntfs-3g/

Though other people say chkdsk in Windows does that better. I do not know.

17

I already tried the ntfs3 with no success. Anyway, I decided to try again now without the /etc/udisks2/mount_options.config file and… IT’S WORKING IN RW!! Thank you @ben79 !

Since the fstab line I previously shared it’s not the configuration I was trying to have (don’t automount the partition at system startup, but mout in Dolphin when required), I modified the line in:

UUID=BAE2A2BEE2A27DEF    /media/silvano/DATA   ntfs3   rw,nosuid,nodev,uid=1001,gid=1007,nofail,x-gvfs-show,umask=000,noauto 0 0

And now I can correctly mount in Dolphin the partition and create files and folders.

Anyway, I still don’t understand why the ntfs partition where the Windows OS is installed doesn’t require an fstab entry to be mounted in rw from Dolphin.

Thank you all!!

18

Yeah! And thanks for the kind words though I seemed to be more of a blithering idiot on this issue.

1 Like
19

I’m saying sharing the data between OS’s on a proprietary filesystem is not a good idea. It may have worked in the past, but it’s not a good idea. It would be better to devote the storage to an external source like an old PC you can run as a server and use SFTP or even SAMBA instead. At the very least, I hope you are making backups of the ntfs partition especially if you are writing to it.