1

Ubuntu 22.04, dual booting with Windows 10 with a shared NTFS drive for data storage. Using Dolphin as my default file manager.

A long journey down the rabbit hole into fine tuning the mounting options for my shared partition (for reasons that are beyond the scope of this posting) has culminated in manually setting up my mounting configuration for my NTFS partition (/dev/sda2) in /etc/fstab (with auto option for auto mounting on startup).

After switching from the default "stock" mounting procedure to my customized one, I noticed that Dolphin had stopped showing folder previews within the shared NTFS partition. A quick search led to an easy fix for that issue: substitute the FUSE based ntfs-3g mounter with the native ntfs3 one. That worked (after dropping nls=utf8 from my fstab entry) and I got my folder previews back in Dolphin after a hot unmount/mount sequence.

However, after rebooting, I lose folder previews again. Unmounting and remounting fixes the problem, which leads me to the following questions:

  • Is the boot/startup mounting procedure cached?
  • Is it possible that the startup mounting of my NTFS partition is still using ntfs-3g?
  • How can I force startup mounting to abide by the fstab configuration?

My fstab line:

UUID=xyz /media/me/DATA ntfs3 rw,auto,users,exec,umask=000,dmask=027,fmask=137,gid=1000,uid=1000,windows_names 0 0

5
  • 1
    In answer to your 3 points: No. Yes, maybe - check your system logs sudo journalctl -b 0. /etc/fstab is already the One True Source of mounting information.
    – waltinator
    Commented Sep 24, 2023 at 23:26
  • If your Windows has "Fast Boot" enabled, it will leave the disk in a state Linux doesn't understand. Turn off Windows' "Fast Boot".
    – waltinator
    Commented Sep 24, 2023 at 23:30
  • @waltinator Fast Boot is off in Windows. Always has been.
    – Makaveli84
    Commented Sep 24, 2023 at 23:44
  • @waltinator Yes, it didn't make sense for the fstab configuration to be cached. Please check my answer below.
    – Makaveli84
    Commented Sep 24, 2023 at 23:46
  • @waltinator please don't post answers as comments. That circumvents the quality control system of the site (voting) and can discourage others from posting actual answers which means the question might never be counted as answered.
    – terdon
    Commented Sep 25, 2023 at 8:07

1 Answer 1

1

Well, after some more digging and a stroke of luck, I think I figured it out! The thing is (and I had omitted this information from the original post because I had completely forgotten about it), prior to going through the fstab route, I had tried setting up an auto-mount of my shared NTFS partition using a systemd service unit (that was placed in /etc/systemd/system/). I was trying to "replace" the automounter configuration without changing the mount point because of existing links and bookmarks. Now my systemd unit had the following directives:

[Unit]
Description=Mount DATA

[Mount]
What=/dev/sda2
Where=/media/me/DATA
Type=ntfs
Options=defaults

[Install]
WantedBy=multi-user.target

And the service's filename was as required: media-me-DATA.mount

After initially fiddling around with that option, I decided to ditch the attempt and go through fstab instead. I disabled the service (systemctl disable media-me-DATA.mount) but left the file hanging in the /etc/systemd/system directory.

Fast forward to fstab mounting where I used the same mounting point as the aforementioned service, and following a reasonable deduction that it seems that the automounter goes through systemd by apparently creating an "on-the-fly" service behind the scenes, and it was obvious that a conflict was occurring. When the automounter was detecting an existing service unit with the right name, it was enabling and activating it instead of creating a new one using the configuration from fstab. And with the existing service configured to use defaults, the conflict was causing the partition to be automounted via ntfs-3g instead of ntfs3.

So the fix without having to sacrifice the mounting point was simply to remove the "hanging" media-me-DATA.mount file from /etc/systemd/system and all works as intended now. Startup automounting now follows the fstab configuration and mounts through ntfs3, and Dolphin shows folder previews for the shared NTFS partition at startup.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .