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
fuse: mount failed: das gerät oder die ressource ist belegt
- Bearbeitet
Gibt es denn Fehlermeldungen nach Befehlen wie z.B:
# mount /dev/sda5 /home/led/storage
oder
# mount -t ntfs-3g /dev/sda5 /home/led/storage
oder
# mount -t ntfs3 /dev/sda5 /home/led/storage
- Bearbeitet
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.
Da kommt leider keine Anzeige.
- Bearbeitet
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
- Bearbeitet
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.
- Bearbeitet
$ 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)
- Bearbeitet
zgrep CONFIG_BLK /proc/config.gz?
Könnte sowas in die Richtung https://lore.kernel.org/all/20240221214626.GB633176@mit.edu/t/#u
Aber ich bin da auch nur am raten jetzt. Bei mir klappt alles (Standard Arch ohne -zen, testing, ...)
- Bearbeitet
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_hiberfile
beim 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-3gremove_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.
- Bearbeitet
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
- Bearbeitet
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...
Kann ich das anpassen?
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?
Thorgrimsson Ist sowas dann ein Bug-Report wärt?
Jo!