ubuntuusers.de

flyheli schrieb:

Wenn ich ein Medium heute beschreiben kann und morgen nicht mehr, da fange ich nicht an in den Internas herumzuwursteln, das sollte ein Betriebssystem schon selbst hinkriegen.

(„Interna“ ist schon Plural, „Internas“ gibt’s nicht.) Du solltest aber nicht von einem Betriebssystem erwarten, dass es das auch mit systemfremden Dateisystemformaten hinkriegt, mit denen du nicht mal sachgerecht umgehst (indem du sie nicht sauber aushängst vorm Runterfahren oder Rausziehen).

Aber wenn ich schon

Intenso […] genutzt zur Datensicherung

lese … meine Datensicherungen vertraue ich wirklich nur hochwertigen Markenprodukten an. Sicherung auf einem FAT-Format, also ohne Besitzer und Dateirechte, wenn du’s zurücksicherst? Hast du dir das gut genug überlegt?

Ich persönlich bin Btrfs-Fan, auch für Backupmedien, aber ext4 sollte es genausogut tun, mit etwas mehr Overhead halt ☺

--ks

flyheli schrieb:

Hallo,

nach dem Update von 14.04 auf 24.04 fällt mir des öfteren auf, daß ich auf von mir am gleichen Rechner formatierte und schon genutzten Speicher-medien (Stick oder Festplatte) nach einer der nächsten Anmeldungen nicht mehr beschreiben kann.

Konkret jetzt ein Intenso 32GB Stick, genutzt zur Datensicherung. Wurde von mir auf diesr Maschine gestern formatiert mit FAT und mit Daten beschrieben. Heute will ich weitere Daten sichern und plötzlich habe ich keine Rechte mehr.

Ein paar Gedanken zu diesem Ansatz:

• FAT ist das denkbar schlechteste Dateisystem für eine Datensicherung: Es unterstützt kein Journaling (wichtig bei vorzeitigen Abziehen 😉 ), wenige Metadaten (immerhin: Timestamps), keinerlei Benutzerrechte oder Snapshots - gut, letzteres ist eher Luxus. Wenn Du den Stick ohnehin nur unter Linux nutzt, bieten sich Dateisysteme wie ext4 oder andere an (siehe Dateisystem).

• Da FAT keine Benutzerrechte nutzt, aber trotzdem welche dargestellt werden, müssen sie irgendwo herkommen. Das passiert beim mount. Wechseldatenträger werden dabei automatisch eingehängt unter /media/<username>/<Disk-Label>. Mach' mal ein

mount | grep fat

in den Optionen des mount-Befehls wird dargestellt, was alles mit an Parametern mitgeliefert wird. Diese kannst Du auch selbst definieren in der fstab, die möglichen Optionen findet man in der Man-Page von mount (1) → Mount Optionen für FAT.

• Kannst Du den Stick zumindest lesen? Auch die Datei-Inhalte? Ich gehe davon aus, dass der hardware-seitige Schreibschutz (falls vorhanden) aufgehoben ist. GPT reparieren falls notwendig (gdisk), evtl ist das wirklich ein Hardware-Problem.

flyheli schrieb:

GParted liefert eine Fehlermeldung:

The backup GPT Table is corrupt, but the primary appears ok , so that will be used.

Nur mal noch so nebenbei.

Die Nutzung von GPT auf einem USB-Stick ist sinnvoll, wenn du große Speichermedien (>2 TB) verwenden oder mehr als vier Partitionen erstellen möchtest. Zudem unterstützt GPT eine bessere Datensicherheit durch eine Backup-Partitionstabelle. Für ältere Systeme, die nur MBR unterstützen, ist es jedoch nicht geeignet.

Da dein T500 kein UEFI hat macht also GPT mal so garkeinen Sinn.

Vielen lieben Dank für Eure Unterstützung, ich dachte, es wäre eine Kleinigkeit, daher habe ich das Problem wohl nicht genau genug beschrieben, daher nochmal genauer:

Im Rahmen einer Datensicherung habe ich sehr viele Kopiervorgänge (durchaus mehr als 20) mit sehr vielen Dateien (durchaus mehrere Tausend) quasi gleichzeitig mit dem Dateimanager in Auftrag gegeben. Kopiert wurde auf über USB angeschlossene Festplatten, diese hatten ein EXT3/EXT4 Dateisystem, Gerät, alter Thinkpad T500 von ca 2010 (wir haben 3 davon und sind sehr zufrieden). Die Datensicherung hat mehrere Stunden gedauert, lief aber zu Ende. Bei einenem der nächsten Systemstarts wollte ich die Sicherung erweitern, hatte aber plötzlich keine Schreibrechte mehr und konnte diese auch nicht herstellen.

Ob an dieser Stelle Dateien korrupt waren, habe ich nicht getestet.

Danach blieb mir (mit meienem Wissen) nichts anderes übrig, als das Medium neu zu formatieren, diesmal FAT und den Kopiervorgang erneut zu starten, diesmal aber langsam, jeweils nur ein Auftrag (mit durchaus sehr vielen Dateien). So scheint es funktioniert zu haben.

Ein USB-Medium ohne 'Aushängen und Auswerfen' abzuziehen, passiert mir nicht mehr, die folgenden Probleme hatte ich schon genug.

In dem oben beschriebenen Fall wurde ein Intenso USB Stick mit FAT formatiert (aus oben genannten Gründen) und auch hier wieder (quasi gleichzeitig) mit sehr vielen Aufträgen und Dateien beschrieben. Der Kopiervorgang wurde immer langsamer und schien nach etwa einer Stunde ohne erkennbaren Fortschritt. So habe ich 'Abbruch' (der Kreis mit dem Stern in der Fortschrittsanzeige) bestätigt und den Rechner heruntergefahren, was sicher eine weitere Viertelstunde gedauert hat, dabei wurde der Stick im Rechner belassen. Leider verhindert Plymouth das Lesen der Meldungen, das muss ich unbedingt noch ändern. Beim nächsten Einstecken erneut das Problem, der nicht vorhandenen Rechte zum Beschreiben.

Nachdem das setzen der Rechte in der Konsole nicht funktionierte wurde GParted genutzt um den Stick zu überprüfen und zeigte diese Fehlermeldung an:The backup GPT Table is corrupt, but the primary appears ok , so that will be used. (2 Partitionen)

Wo das GPT herkommt und was es bedeuted, weis ich nicht. Aber, der Stick wurde vormals als Ubuntu Startmedium genutzt, vielleicht hat es damit zu tun ?

Darauf hin ging ich von einem Defekt des Dateisystems auf dem Stick aus und habe ihn neu mit EXT3/EXT4 formatiert und das Kopieren anschliessend neu ganz langsam Auftrag für Auftrag erneut ausgeführt. Da ich weiterhin Schreibrechte auf dem Stick habe, gehe ich davon aus, das das funktioniert hat.

Fazit: es scheint riskant mehrere Kopiervorgänge gleichzeitig über den Dateimanager in Auftrag zu geben...

Jetzt komme ich der Sache näher.....

Das Auswerfen/Aushängen ergibt eine Fehlermeldung, hier über die Konsole ausgeführt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

axel@axel-ThinkPad-T500:~$ eject /dev/sdb
eject: /dev/sdb kann nicht geöffnet werden: Keine Berechtigung
axel@axel-ThinkPad-T500:~$ sudo eject /dev/sdb
[sudo] Passwort für axel: 
eject: /dev/sdb kann nicht geöffnet werden: Das Gerät oder die Ressource ist belegt
axel@axel-ThinkPad-T500:~$ sudo eject /dev/sdb1
eject: /dev/sdb kann nicht geöffnet werden: Das Gerät oder die Ressource ist belegt
axel@axel-ThinkPad-T500:~$ sudo eject /dev/sdb4
eject: /dev/sdb kann nicht geöffnet werden: Das Gerät oder die Ressource ist belegt
axel@axel-ThinkPad-T500:~$ 

Es laufen keine weiteren Programme, ausser Firefox.

Wie finde ich heraus, welcher Prozess den Stick belegt und wie kann ich ihn beenden ?

→ eine Viertelstunde später funktionierte das Aushägnen wieder ?????

Irgendetwas läuft da wohl im Hintergrund ab, aber was ?

flyheli schrieb:

Wo das GPT herkommt und was es bedeuted, weis ich nicht. Aber, der Stick wurde vormals als Ubuntu Startmedium genutzt, vielleicht hat es damit zu tun ?

Ja, definitiv. Du musst unterscheiden zwischen Partitionstabellen und Dateisystemen. Den Stick als Gerät „formatierst“ du mit einer Partitionstabelle, und da ist vom Ubuntu-ISO noch GPT drauf. In dieser GPT kannst du jetzt Partitionen löschen, neue anlegen und sie mit vFAT oder ext4 neu formatieren, wie du willst, das ändert an der GPT überhaupt gar nichts.

Bei einem Stick kannst du auch die Partitionstabelle ganz entfernen (ich mache das mit dem gnome-disk-utility, „Laufwerk formatieren“) und das Gerät komplett ohne Partitionstabelle mit einem Dateisystem formatieren. Das sind dann aber zwei Schritte.

Wie finde ich heraus, welcher Prozess den Stick belegt

Mit lsof. Nehmen wir an, dein Stick ist unter /media/user/usbstick gemountet, dann sollte ein

lsof /media/user/usbstick

die Antwort liefern.

und wie kann ich ihn beenden ?

mit kill wie immer.

--ks

Hallo flyheli,

Bitte organisiere dir bitte mal einen externen Datenträger von einem anderen (bedeuteren) Hersteller und versuche es nochmal.

PS: hatte auch schon ca. 20 "zerbröselnde" von INTENSO in der Hand.

Gruss Lidux

flyheli schrieb:

Hallo,

1 2 3 4 5 6

axel@axel-ThinkPad-T500:~$ sudo chmod 777 -c -R /dev/sdb1 [sudo] Passwort für axel: der Modus von '/dev/sdb1' wurde von 0660 (rw-rw----) in 0777 (rwxrwxrwx) geändert axel@axel-ThinkPad-T500:~$ sudo chmod 777 -c -R /dev/sdb4 der Modus von '/dev/sdb4' wurde von 0660 (rw-rw----) in 0777 (rwxrwxrwx) geändert axel@axel-ThinkPad-T500:~$ Code

Wo ist der Fehler ?

Moin, was mich irritiert ist, warum versuchst du direkt auf ein device zu schreiben? Nach meinem Verständnis mountet man doch ein Medium erstmal?

sicher.

Ich habe Automount eingestellt, d.h. ein eingestecktes Gerät wird automatisch gemounted. Ich kann das Gerät in der Bar (links der Balken) sehen und ich konnte es mit 'Dateien' ansehen und auch Dateien lesen, aber nicht schreiben. Die zitierte Anweisung verändert die Benutzerrechte auf die komplette Device, was im Normalfall auch funktioniert. Hier war wohl das Dateisystem beschädigt und es war eine Neuformatierung notwendig.