Vor ein paar Tagen war schon ein mal ein Problem mit ntfs aufgetaucht.
Siehe:
https://forum.archlinux.de/d/35057-automatisches-mounten-usb-festplatte/18
Vielleicht ist dein Problem auch durch den neuen Treiber ntfs3 bedingt.
Die Lösung war folgende:

GerBra
echo "blacklist ntfs3" >> /etc/modprobe.d/blacklist.conf

als root.
//Edit: Mit sudo funktioniert obiger Befehl nicht, nutze su um zum Superuser zu werden.
Rebooten. Testen.

Hab ich mal ausprobiert allerdings ohne Änderung.
Tatsächlich fahre ich die Lösung des Threaderstellers ntfs-3g in fstab zu schreiben schon seit Jahren.
Auszug aus fstab (wobei die Zeile eigentlich gerade auskommentiert ist da ich sonst nicht booten kann:
# /dev/sda5 LABEL=Storage
UUID=1A20D4F520D4D8B9 /home/led/storage ntfs-3g uid=1000,gid=985,rw,auto,dev,exec,async 0 1

Gibt es denn Fehlermeldungen nach Befehlen wie z.B:
# mount /dev/sda5 /home/led/storage oder
# mount -t ntfs-3g /dev/sda5 /home/led/storageoder
# mount -t ntfs3 /dev/sda5 /home/led/storage

Die ersten beiden liefern folgende Fehlermeldung:
fuse: mount failed: das gerät oder die ressource ist belegt.

die dritte (nachdem ich die blacklist.conf gelöscht habe):
mount: /home/led/storage: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/sda5 ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.
dmesg(1) könnte nach einem fehlgeschlagenen mount-Systemaufruf
weitere Informationen liefern.

Ein
fuser --mount /dev/sda5
könnte dir anzeigen welcher Prozess auf /dev/sda5 zugreift und das Mounten verhindert.

Lege mal ein neues Verzeichnis auf / als Mountpint an:
# mkdir /storage
Und vielleicht bekommen wir mehr Hinweise mit:
# mount --verbose -r /dev/sda5 /storage
# mount --verbose -rw /dev/sda5 /storage
# dmesg

Also mount als readonly funktioniert. Das hatte ich ganz auch schonmal kurz beschrieben das ich das ausprobiert habe.
Letzteres verändert zwar nicht die Meldung aber dafür liefert dmesg jetzt folgendes:
/dev/sda5 can't open blockdev

lsblk /dev/sda5
losetup
grep "sda5" /proc/mdstat
dmsetup table | grep ' 8:5'
find /sys -name "sda5"
ls -l /proc/*/fd/* | grep sda

Welche Kernelversion hast du laufen? Vor ein zwei Jahren oder so war da mal was mit false positives beim exclusive mounten...

Bei einem tatsächlich benutzten Gerät, darf eigentlich auch readonly mount nicht funktionieren (etwas anderes schreibt, und der readonly mount zeigt nur noch korrupte Daten an - das will man eigentlich nicht).

Benutzt du zufällig umount --lazy? Oder irgendwas mit Namespaces?

Das gängige Problem bei NTFS ist ja sonst das aktive Hibernate/Fastboot in Windows... da gibts dann aber auch eine eindeutige Meldung dazu.

$ lsblk /dev/sda5
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda5 8:5 0 198,4G 0 part

$ losetup

$ grep "sda5" /proc/mdstat
grep: /proc/mdstat: Datei oder Verzeichnis nicht gefunden
$ dmsetup table | grep ' 8:5'
/dev/mapper/control: open failed: Keine Berechtigung
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.197 (2023-11-21) and kernel driver (unknown version).
Command failed.

Ich schätze mal da war nur das Problem das ichs nicht als root ausgeführt habe? (aber falls doch wichtig war...)
# dmsetup table | grep ' 8:5'

# find /sys -name "sda5"
/sys/class/block/sda5
/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda5
# ls -l /proc/*/fd/* | grep sda
ls: Zugriff auf '/proc/26261/fd/255' nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf '/proc/26261/fd/3' nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf '/proc/26262/fd/3' nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf '/proc/26262/fd/4' nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf '/proc/self/fd/255' nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf '/proc/self/fd/3' nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf '/proc/thread-self/fd/255' nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf '/proc/thread-self/fd/3' nicht möglich: Datei oder Verzeichnis nicht gefunden

Ich hoffe ihr könnt damit was anfangen ich verstehs leider nicht mehr ;(
ah ja Kernel Version ist Linux 6.8.0-zen1-1-zen (testing Repos sind aktiviert; sorry falls das jetzt viel zu spät kommt)

Ergänzung: ich benutze nicht umount --lazy oder namespaces (zumindest nicht bewusst)

Habe mit etwas Googeln herausbekommen, dass Windows die Partition bei hibernate auf 'nur lesend' setzt. Das behebt man entweder durch das Starten und korrekte Herunterfahren von Windows oder durch die Option -remove_hiberfilebeim mounten in Linux.
Siehe:
https://forums.debian.net/viewtopic.php?t=141808
https://linux.die.net/man/8/mount.ntfs-3g

remove_hiberfile
Unlike in case of read-only mount, the read-write mount is denied if the NTFS volume is hibernated. One needs either to resume Windows and shutdown it properly, or use this option which will remove the Windows hibernation file. Please note, this means that the saved Windows session will be completely lost. Use this option under your own responsibility.

    tuxnix Habe mit etwas Googeln herausbekommen, dass Windows die Partition bei hibernate auf 'nur lesend' setzt. Das behebt man entweder durch das Starten und korrekte Herunterfahren von Windows oder durch die Option -remove_hiberfilebeim mounten in Linux.
    Siehe:
    https://forums.debian.net/viewtopic.php?t=141808
    https://linux.die.net/man/8/mount.ntfs-3g

    remove_hiberfile
    Unlike in case of read-only mount, the read-write mount is denied if the NTFS volume is hibernated. One needs either to resume Windows and shutdown it properly, or use this option which will remove the Windows hibernation file. Please note, this means that the saved Windows session will be completely lost. Use this option under your own responsibility.

    Das Problem ist mir grundsätzlich bekannt.
    Hab es auch mal getestet:

    # ntfs-3g -o remove_hiberfile /dev/sda5 /Storage
    fuse: mount failed: Das Gerät oder die Ressource ist belegt

    Hätte mich aber auch gewundert wenn das was gebracht hätte, da zwischen Auftreten des Fehlers nur ein Update mit anschließendem reboot stattfand.

    frostschutz zgrep CONFIG_BLK /proc/config.gz?

    # zgrep CONFIG_BLK /proc/config.gz
    CONFIG_BLK_CGROUP=y
    CONFIG_BLK_DEV_INITRD=y
    CONFIG_BLK_RQ_ALLOC_TIME=y
    CONFIG_BLK_CGROUP_RWSTAT=y
    CONFIG_BLK_CGROUP_PUNT_BIO=y
    CONFIG_BLK_DEV_BSG_COMMON=y
    CONFIG_BLK_ICQ=y
    CONFIG_BLK_DEV_BSGLIB=y
    CONFIG_BLK_DEV_INTEGRITY=y
    CONFIG_BLK_DEV_INTEGRITY_T10=y
    # CONFIG_BLK_DEV_WRITE_MOUNTED is not set
    CONFIG_BLK_DEV_ZONED=y
    CONFIG_BLK_DEV_THROTTLING=y
    CONFIG_BLK_DEV_THROTTLING_LOW=y
    CONFIG_BLK_WBT=y
    CONFIG_BLK_WBT_MQ=y
    CONFIG_BLK_CGROUP_IOLATENCY=y
    CONFIG_BLK_CGROUP_FC_APPID=y
    CONFIG_BLK_CGROUP_IOCOST=y
    CONFIG_BLK_CGROUP_IOPRIO=y
    CONFIG_BLK_DEBUG_FS=y
    CONFIG_BLK_DEBUG_FS_ZONED=y
    CONFIG_BLK_SED_OPAL=y
    CONFIG_BLK_INLINE_ENCRYPTION=y
    CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
    CONFIG_BLK_MQ_PCI=y
    CONFIG_BLK_MQ_VIRTIO=y
    CONFIG_BLK_PM=y
    CONFIG_BLK_MQ_STACKING=y
    CONFIG_BLK_DEV=y
    CONFIG_BLK_DEV_NULL_BLK=m
    CONFIG_BLK_DEV_FD=m
    # CONFIG_BLK_DEV_FD_RAWCMD is not set
    CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m
    CONFIG_BLK_DEV_LOOP=m
    CONFIG_BLK_DEV_LOOP_MIN_COUNT=0
    CONFIG_BLK_DEV_DRBD=m
    CONFIG_BLK_DEV_NBD=m
    CONFIG_BLK_DEV_RAM=m
    CONFIG_BLK_DEV_RAM_COUNT=16
    CONFIG_BLK_DEV_RAM_SIZE=16384
    CONFIG_BLK_DEV_RBD=m
    CONFIG_BLK_DEV_UBLK=m
    CONFIG_BLKDEV_UBLK_LEGACY_OPCODES=y
    CONFIG_BLK_DEV_RNBD=y
    CONFIG_BLK_DEV_RNBD_CLIENT=m
    CONFIG_BLK_DEV_RNBD_SERVER=m
    CONFIG_BLK_DEV_NVME=m
    CONFIG_BLK_DEV_SD=y
    CONFIG_BLK_DEV_SR=m
    CONFIG_BLK_DEV_BSG=y
    CONFIG_BLK_DEV_3W_XXXX_RAID=m
    CONFIG_BLK_DEV_MD=m
    CONFIG_BLK_DEV_DM_BUILTIN=y
    CONFIG_BLK_DEV_DM=m
    CONFIG_BLK_DEV_PMEM=m
    CONFIG_BLK_DEV_IO_TRACE=y

    OK, könnte ne neue Eigenart von Kernel 6.8 sein.

    BLK_DEV_WRITE_MOUNTED [=y]
    Prompt: Allow writing to mounted block devices

    Default =y, bei dir =n, vielleicht verschluckt sich da was. Ist jetzt aber auch nur geraten.

    Ich habe kernel 6.8.0 noch nicht im Einsatz, ich warte da meistens auf die x.x.5 version weils vorher fast immer ein paar schräge Bugs gibt ;-)

    Das Problem gabs vor einer Weile (1-2 Jahre?) schon mal... war damals auch eine Kerneländerung. Finde aber gerade die Threads dazu nicht...

    Wenn du den Kernel neu compilierst? Sonst eben auf 6.7.x zurückgehen und nochmal probieren?

    Wie gesagt nur geraten daß da ein Zusammenhang bestehen könnte. Kann auch was anderes sein.

    Danke für die ganzen Hinweise 😉
    Der Downgrade auf Linux-zen-6.7.9 hat geholfen. Jetzt läuft alles wieder so wie es soll 😉
    Ist sowas dann ein Bug-Report wärt?

    • tuxnix hat auf diesen Beitrag geantwortet.