(K)ubuntu kein Zugriff auf interne Festplatten

PHuV schrieb:
Mounts per UUID? Warum so eine Grütze? Direkt die Devices angeben mit Filesystem und dann den Benutzer dazupacken.

Blöde Frage, wie kommt es zu den Devices ssd und hdd. Ist das von einer alten Installation oder woher kommt das? Mit welchem User wurde das dann damals erstellt?

Code:
/dev/sdc1 /home/user/hdd ext4 rw,uid=123,gid=123 0 2
/dev/sdb1 /home/user/ssd ext4 rw,uid=123,gid=123 0 2
uid und gid muß durch Deinen Benutzer ersetzt werden.
Das mit den UUIDs ist eine solidere Lösung. Bei mir haben bei einem BIOS-Update mal die "Chipset"- und die "zusatz"-SATA-Ports die Reihenfolge getauscht. Da war natürlich dann die fstab nicht mehr passend :D

(Und auch bei virtuellen Maschinen, wo im zweifelsfall Platten sehr flott hin und wieder weg kommen, ist so eine UUID das einzig eindeutige).
 
  • Gefällt mir
Reaktionen: AlphaKaninchen
UUIDs sind tatsächlich keine Grütze ;) Werden Laufwerke hinzugefügt, die Reihenfolge ändert sich aus irgendwelchen Gründen oder Windows ist der Meinung eine zweite Wiederherstellungspartition anzulegen und ändert dadurch die Nummerierung, erkennt Linux anhand dieser ID trotzdem die richtige Partition und kann sie mounten.

Ansonsten bootet das System eventuell gar nicht mehr.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen, Alexander2, brotkastn und eine weitere Person
Vor allem: In der hier vorliegenden fstab stehen die UUIDs schon drin, @smashcb muss also eigentlich nur die Verzeichnispfade auf sinnvolle Werte setzen...
 
Für produktive Systeme klar UUIDs, wo ich mit zig Plattenstabeln und Protokollen mit iSCSI, Luns, Fibrechannel und Co. rumtunen muß, ist das ja ok. Aber doch nicht im privaten Umfeld, wo die meisten mit sowas gar nichts anfangen können. Mal ehrlich, wer merkt sich UUID=aa9d13cf-5d0b-4ba6-a627-7a1f9be22dc8 oder /dev/sdb1 besser?
Ergänzung ()

brotkastn schrieb:
Das mit den UUIDs ist eine solidere Lösung. Bei mir haben bei einem BIOS-Update mal die "Chipset"- und die "zusatz"-SATA-Ports die Reihenfolge getauscht. Da war natürlich dann die fstab nicht mehr passend :D
Wie oft mußtest Du das schon machen?
brotkastn schrieb:
(Und auch bei virtuellen Maschinen, wo im zweifelsfall Platten sehr flott hin und wieder weg kommen, ist so eine UUID das einzig eindeutige).
Dann reden wir hier aber auch von mehreren VMs auf einem Server oder Serverarray, was bestimmt so privat seltenst vorkommt, oder? 😉

Haltet mich für altmodisch und altbacken, für zu Hause immer
1629230970134.png
-Prinzip. 🤘
 
Zuletzt bearbeitet:
PHuV schrieb:
Mal ehrlich, wer merkt sich UUID=aa9d13cf-5d0b-4ba6-a627-7a1f9be22dc8 oder /dev/sdb1 besser?
Es ist beides egal, weil mir nichts von beiden sagt, welche Platte das jetzt ist. Am Ende muss ich es eh nachschauen und kann es dann auch kopieren.
 
  • Gefällt mir
Reaktionen: Alexander2, fixedwater und AlphaKaninchen
PHuV schrieb:
Wie oft mußtest Du das schon machen?
Das mit dem BIOS war einmalig, aber das Platten getauscht haben gab es öfter. Müssten nicht Mal SATA Platten sein, wenn damals im Cardreader etwas gesteckt ist, dann war der zum Teil sda ;)

PHuV schrieb:
Dann reden wir hier aber auch von mehreren VMs auf einem Server oder Serverarray, was bestimmt so privat seltenst vorkommt, oder? 😉

Haltet mich für altmodisch und altbacken, für zu Hause immer Anhang anzeigen 1113522-Prinzip. 🤘
Beides. Daheim steht halt das nas im Keller, auf dem Laufen ein paar VMs. Da kommt das schon auch Mal vor. In der Arbeit im RZ häufiger ;)

Aber, eigentlich langt für das Beispiel ja eine externe Platte, die zuverlässig immer am selben mountpoint hängen soll - unabhängig davon ob noch 2 USB Sticks stecken.
 
PHuV schrieb:
Für produktive Systeme klar UUIDs, wo ich mit zig Plattenstabeln und Protokollen mit iSCSI, Luns, Fibrechannel und Co. rumtunen muß, ist das ja ok. Aber doch nicht im privaten Umfeld, wo die meisten mit sowas gar nichts anfangen können. Mal ehrlich, wer merkt sich UUID=aa9d13cf-5d0b-4ba6-a627-7a1f9be22dc8 oder /dev/sdb1 besser?
Das liest sich so, als wärst du der Meinung, dass dies eine bewusste Entscheidung des TE gewesen wäre. Dabei ist die Identifizierung per UUID seit Jahren bei allen Distributionen der Standard. Eine Umstellung auf die klassischen Devicenamen dürfte insbesondere den Einsteiger überfordern.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen
PHuV schrieb:
Blöde Frage, wie kommt es zu den Devices ssd und hdd. Ist das von einer alten Installation oder woher kommt das? Mit welchem User wurde das dann damals erstellt?
ich hab das dummerweise bei der Installation so angelegt, an dem Punkt wo man die Festplatten partionieren kann.

Zu dem Rest bin ich noch nicht gekommen, dass umzusetzen.

Ja der username ist "user"
 
Erstmal das da ein Ordner /hdd und ein Ordner /ssd ist und darin ne Partition gemountet entspricht nicht dem standard :-) aber trotzdem geht dadurch nichts kaputt oder so.

Für die Tägliche Nutzung ist es einfacher erreichbar, wenn die auch in deinem Home Verzeichnis gemountet sind weil jeder dateimanager oder dateidialog erstmal in deinem Home Verzeichnis starten dürfte.

Mit meiner Festplatte für die Sicherungen (ext4 formatiert und ist auch nur für Linux, hab auch kein anderes BS) habe ich bei der ersteinrichtung natürlich in dem fall auch erstmal ein chown ... gemacht aber die wird ja auch nur an dem Rechner verwendet und war zuvor leer.

man kann das in der fstab auch so eintragen, das man die nicht immer angeklemmt haben muss.
 
Alexander2 schrieb:
Erstmal das da ein Ordner /hdd und ein Ordner /ssd ist und darin ne Partition gemountet entspricht nicht dem standard :-) aber trotzdem geht dadurch nichts kaputt oder so.
Manchmal möchte man aber etwas erreichbar für jeden User auf der Kiste machen ohne an den Berechtigungen dann von /home/Benutzername/Datenablage/ssd herumfummeln zu müssen. Da bietet es sich dann an ein Verzeichnis im root zu erstellen wo dann die Partition der SSD reingemountet wird. Ich mach das bei einer externen Platte auch, die mounte ich dann nach /backup

Jedenfalls wenns gemountet ist, ist es egal ob nach /ssd oder /foo/bar/ssd, wenn man das Verzeichnis nicht betreten kann, dann stimmt was an den Berechtigungen nicht - um ein Verzeichnis betreten zu düfen muss es "ausführbar" sein, am besten sowas wie 755 oder wenn man es restriktiver will 750 bzw gar 700.
 
fischfilet schrieb:
Manchmal möchte man aber etwas erreichbar für jeden User auf der Kiste machen ohne an den Berechtigungen dann von /home/Benutzername/Datenablage/ssd herumfummeln zu müssen.


Dafür gibt es doch /mnt und /media
 
HuhnMitHut schrieb:
Dafür gibt es doch /mnt und /media
Schon, aber manche wollen es in einem kurzen Verzeichnis direkt im root haben wie zum Beispiel

/backup
/data
/ext
/hdd
/ssd

Anstatt diese als Unterverzeichnis von /media zu benutzen.
 
Hi

Vielen Dank für eure Hilfe !

Ich fasse kurz zusammen was genau ich gemacht hab :

in der Konsole
sudo nano /etc/fstab eingeben

in der Datei fstab hab ich dann folgendes eingegeben ( "user" ist mein Benutzername)

# /hdd was on /dev/sdc1 during installation UUID=c9440c48-9ea1-4bfa-b7c7-87d57bdb3c1c /home/user/Datenablage/hdd ext4 defaults 0 2 # /ssd was on /dev/sdb1 during installation UUID=aa9d13cf-5d0b-4ba6-a627-7a1f9be22dc8 /home/user/Datenablage/ssd ext4 defaults 0 2

danach
sudo mount -a

hier gab es die Fehlermeldung das es den Einhaengepunkt nicht gibt, daher hab ich schnell die Ordner Datenablage und die Unterordner ssd und hdd erstellt.

Dann war die Fehlermeldung weg.

Dann war noch das Problem, das mir die Datenträger immer noch nicht gehörten.

Also per Konsole

sudo chown -R user /home/user/Datenablage/ssd
und
sudo chown -R user /home/user/Datenablage/hdd

Jetzt hab ich Zugriff auf die Platten, auch nach dem Neustart :)

Danke .
 
Zuletzt bearbeitet:
fixedwater schrieb:
Und jetzt funktionierts wie gewünscht?
ja jetzt geht alles wie gewünscht ! (Hab meinen Beitrag drüber nochmal ergänzt)
 
Zuletzt bearbeitet:
.... und sichere Dir die fstab... Kannst Du auch nach einer Neuinstallation wieder genau so verwenden...
 
  • Gefällt mir
Reaktionen: smashcb
Da ich mein System durch eine dumme Spielerei neu aufgesetzt hab, konnte ich das ganze jetzt etwas detailierte Betrachten.

Ich hab einfach die manuelle Einbindung während der Installation gelassen und die Software das selber machen lassen.

Dabei hatte ich jetzt den sonderbaren Fall, dass die HDD eingebunden war und ich auch auf die Platte schreiben und lesen konnte, aber ich konnte keine Dateien löschen.

Die SSD wurde zwar eingebunden, ich konnte aber keine Ordner erstellen oder sonstiges. Nur lesen.
Allerdings konnte Photorec Bilder darauf speichern, obwohl es doch auch durch Sudo keine höheren Rechte bekommen hat, oder ?

Jetzt geht erstmal alles wieder, das fand ich am Anfang etwas komisch. So änlich hat es sich aber mit Photorec auch vorher schon verhalten.
 
Das hat jetzt aber nichts mit dem Problem zu tun, daß das Zielverzeichnis zum Mounten nicht vorhanden ist.
Wenn du nur ein gemountetes Verzeichnis lesen kannst, sind eigentlich immer fehlende Zugriffsrechte Schuld.
Das ist Linux sicherer aber auch umständlicher.
 
Zurück
Oben