Benutzerrechte auf Ordner & Dateien?

[X-Worf]

Ich habe den "Dokumente"-Ordner von Benutzer A (ohne admin-Rechte) auf mein zweites Laufwerk (ext4) kopiert. Nun wollte ich mit dem Adminprofil die odt.-Dateien bearbeiten. Leider muss ich feststellen, dass ich mit dem Adminprofil nur Leserechte habe. Das eigentliche Ziel ist mir eine Hilfsdatei für den Linuxeinstieg anzufertigen, dass ich abwechselnd mit Adminprofil, Benutzer A, aber vielleicht auch mal noch mit einem Benutzer B bearbeiten kann. Auch in Zukunft möchte ich gern die internen Laufwerke als Datenablagen nutzen, auf die jeder Nutzer vollen Zugriff hat. (Den Zugriff zu sperren, z.B. auf das Backup-Laufwerk, wollte ich übers manuelle Einhängen bewerkstelligen).

Was muss ich beachten, damit das klappt, oder ist das so unter Linux gar nicht vorgesehen/praktikabel? (Fedora 41 KDE)
Muss ich meine Abläufe ändern?



Liegt es am Dateisystem ext4? Sollte ich besser btrfs nehmen, oder irgendetwas anderes?

Liegt es am Einhängepunkt?
(Habe bemerkt, dass das dritte Laufwerk anders eingehangen wird, allerdings habe ich dort auch nocht kein Einhängepunkt definiert)

Muss man beim Partittioneren passende Einstellungen vornehmen? (Die KDE Partitionsverwaltung wurde genutzt. Mit fstab bin ich noch nicht vertraut. Von chmod habe ich erst das erste Mal gelesen. GParted noch nicht ausprobiert)

 

[madmax2010]

setz die rechte über die Gruppe.

 

[X-Worf]

Also darüber
https://www.shellbefehle.de/befehle/chmod/
irgendwie?

Grundsätzlich soll das auch mit allen anderen Dateien und Ordnern in Zukunft klappen.

 

[BFF]

Bau Dir eine gemeinsame Ablage ausserhalb der home Verzeichnisse. @X-Worf

 

[Donnerkind]

Eine Datei hat immer genau ein Benutzerkonto als Besitzer. Dateiberechtigungen werden für drei getrennte Kategorien gespeichert: für ihren Besitzer, ihre Gruppe und für alle anderen. Damit mehrere Benutzerkonten auf die Datei zugreifen können, müssen sie also entweder einer gemeinsamen Gruppe angehören, zu der dann auch die Datei gehört (in dem Fall muss dann die Gruppenberechtigung passen), oder die Gruppen passen nicht zusammen, dann muss die Berechtigung für den Rest passen.

Um alle Fälle abzudecken, gibst du der Datei eine Berechtigung von 666 bzw. rw-rw-rw-. Damit kann jedes Benutzerkonto lesend und schreibend zugreifen, egal ob Besitzer oder nicht und Mitglieder der Dateigruppe oder nicht.

Ein anderes Dateisystem (das für sich keine Berechtigungen unterstützt, etwa exfat) hilft nur dann, wenn in dessen Mountoptionen entsprechende Standard-Berechtigungen definiert werden, sodass alle seine Dateien die entsprechenden Berechtigungen haben.

 

[foofoobar]

..... Adminprofil ......

In mehreren Jahrzehnten Unix ist mir derartiges unter Unix noch nicht untergekommen.
Was ist das?

Tipp: https://de.wikipedia.org/wiki/Setgid

 

[rgbs]

Adminprofil, Benutzer A, aber vielleicht auch mal noch mit einem Benutzer B

Bei der Installation wird ein Benutzer angelegt, welcher Mitglied der Gruppe (bei Fedora) wheel ist.
Dieser kann administrative Aufgaben ausführen, wenn dem Befehl "sudo" vorangestellt wird und er dann sein Passwort eingegeben hat.
Siehe hierzu auch: https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/
Für Ordner ausserhalb des Home Verzeichnisses, z.B. für ein extra Datenlaufwerk kann der Benutzer dann mit "sudo chown ...." den Besitz der Ordner und der darin enthaltenen Dateien übernehmen, wobei die Zugriffsrechte automatisch mit gesetzt werden.

Gruß
R.G.

 

[foofoobar]

Für Ordner ausserhalb des Home Verzeichnisses, z.B. für ein extra Datenlaufwerk kann der Benutzer dann mit "sudo chown ...." den Besitz der Ordner und der darin enthaltenen Dateien übernehmen, wobei die Zugriffsrechte automatisch mit gesetzt werden.

Maximal wird bei chown das suid-Bit zurückgesetzt, ansonsten bleiben die Rechte stehen.
Und chown ist es auch komplett latte wo ein File liegt, solange das konkrete Filesystem unix-like user unterstützt.

 

[rgbs]

ansonsten bleiben die Rechte stehen

Also wenn ich mit gparted ein Partition erstelle gehört die root und ich kann dort nicht schreiben und auch den Papierkorb nicht sehen, weil mir die Zugriffsrechte fehlen.
Nachdem ich mit chown den Besitz übernommen habe, klappt das.

Gruß
R.G.

 

[foofoobar]

https://linux.die.net/man/2/stat :

struct stat {
    dev_t     st_dev;     /* ID of device containing file */
    ino_t     st_ino;     /* inode number */
    mode_t    st_mode;    /* protection */
    nlink_t   st_nlink;   /* number of hard links */
    uid_t     st_uid;     /* user ID of owner */
    gid_t     st_gid;     /* group ID of owner */
    dev_t     st_rdev;    /* device ID (if special file) */
    off_t     st_size;    /* total size, in bytes */
    blksize_t st_blksize; /* blocksize for file system I/O */
    blkcnt_t  st_blocks;  /* number of 512B blocks allocated */
    time_t    st_atime;   /* time of last access */
    time_t    st_mtime;   /* time of last modification */
    time_t    st_ctime;   /* time of last status change */
};

st_mode sind die Rechte, nicht st_uid oder st_gid.

 

[rgbs]

Wenn man es jetzt wirklich streng nimmt, hast Du natürlich recht.
Es wird ja geregelt, was der Eigentümer darf, die Gruppe des Eigentümers darf und was Andere dürfen.
Aber praktisch bedeutet das halt, dass man, wenn man den Besitz übernommen hat, meist auch die benötigten Rechte hat.
Also ich habe in den paar Tagen, die ich jetzt mittlerweile mit Linux unterwegs bin chmod noch nie gebraucht.

Gruß
R.G.

 

[foofoobar]

Wenn man es jetzt wirklich streng nimmt, hast Du natürlich recht.
Es wird ja geregelt, was der Eigentümer darf, die Gruppe des Eigentümers darf und was Andere dürfen.
Aber praktisch bedeutet das halt, dass man, wenn man den Besitz übernommen hat, meist auch die benötigten Rechte hat.
Also ich habe in den paar Tagen, die ich jetzt mittlerweile mit Linux unterwegs bin chmod noch nie gebraucht.

Bei modernen Linuxen/Distris ist auch das verschenken von Files an andere nicht mehr so ohne weitere möglich. Was eigentlich ein schön einfaches Verfahren für die Implementierung von privilege separation ist.

-> https://man7.org/linux/man-pages/man7/capabilities.7.html

 

[rgbs]

Bei modernen Linuxen/Distris ist auch das verschenken von Files an andere nicht mehr so ohne weitere möglich.

So wie ich das verstehe ist das dann halt die Nummer mit sudo chown.

Gruß
R.G.

 

[Pummeluff]

Man kann das entweder über das setgid-Bit oder über ACLs regeln. Da ACLs bei 2 Nutzern etwas über das Ziel hinausschießen, erklär ich mal kurz das Vorgehen mit Setgid:

0. Annahmen

• Nutzer A: user_a, Gruppe users
• Nutzer B: user_b, Gruppe users
• Wir wollen ein gemeinsames Verzeichnis shared auf externer Platte, die nach /mnt/ext/ gemountet ist.
• Wir arbeiten für die Einrichtung als Root!. Alternativ klemmt halt der "Adminnutzer" vor jeden Befehl ein sudo.

1. Gruppe users prüfen
Je nach Distribution landen angelegte User nicht in der Gruppe users, sondern bekommen als Gruppenname eine dem Nutzer gleichlautende Gruppe. Das kann man prüfen mit:

id user_a

# Fall 1: Gruppe user ist zugeordnet: Dann mit 2. weitermachen
uid=1000(user_a) gid=100(users)

# Fall 2: Nutzerbezogene Gruppe: Dann hier weiter
uid=1000(user_a) gid=1000(user_a)

Fall 2:
Wir müssen die beiden Nutzer in die gemeinsame Gruppe users eintragen.

gpasswd -a user_a users
gpasswd -a user_b users

2. Verzeichnis anlegen und konfigurieren

mkdir /mnt/ext/shared

# Wir ändern die Gruppe des Verzeichnisses auf users
chgrp users /mnt/ext/shared

# Rechte: Jeder Gruppennutzer darf reinschreiben. Und die Rechte sollen vererbt werden.
chmod 2775 /mnt/ext/shared

Damit sollten beide Nutzer im gemeinsamen Verzeichnis alle dort erstellten Dateien bearbeiten können. Die Lösung hier ist der saubere Unix-Weg.

 

[X-Worf]

🤧 -> und jetzt versuche ich mich malwieder hiermit zu beschäftigen...

---

@alle
Vielen Dank für die zahlreichen Antworten! Ich verstehe leider nur die Hälfte...

Grundsätzlich hilft es mir, wenn ihr gute Quellen zu Hilfen mitpostet, damit ich die Beiträge besser verstehen kann. Denn seit MS-DOS hatte ich keine Berühungspunkte mehr Befehlseingaben und ich stehe da noch mitten im Wald und sehe keine Bäume...

Ich weiß, dass habt ihr schon, aber mit fehlt häufig noch das systemische Verständnis. Wie/wo etwas eingebunden ist und im Zusammenhang steht.
Derzeit kapiere ich nichtmal wie ich in der Konsole in der man page navigiere. Und überhaupt habe ich grundsätzliche Schwierigkeiten die unix-Sprache samt man pages zu verstehen.

Ich kann natürlich auch selber "googlen", aber die Qualtiät der Suche hängt vom Verständis der Antworten ab und darüber hinaus sind Suchmaschienen so "fucking-money" geleitet, dass man fast schonwieder zurück zu irgendwelchen Boards müsste - bevor es Suchmaschienen gab - damit man überhaupt gehaltvolle Informationen findet.
Die aufgesplitterne Linux-Welt samt Distros/DEs machen es da auch noch schwerer zu verstehen und passend zu suchen.

---

Ich bin mir noch nicht sicher, ob die Lösungen Beispiele sind, die sich auf einzelne Dateien/Ordner beziehen, oder breiter aufgestellt sind. Daher nochmal die Situation und Zielsetzung detailierter:

Ich habe 3 interne Laufwerke (siehe Bild, #1)

• Die 1TB ist meine "systemplatte", ich glaube "/". Die home-Strukter möchte ich eigentlich für jeden "users"-Nutzer nutzen und die Daten dann an diverse andere Orte (intern und extern) kopieren können.

Wenn nötig, oder bedeutend einfacher, würde ich außerhalb von home eine Struktur anlegen.​

• Die 2TB soll meine "datenplatte" werden, wo eine Kopie der Daten von verschiedenen "users" kopiert wird, aber auch vereinzelt vom "user"-Konto. ( = mein Wunsch).

Der Regelfall wird aber sein, dass nur die Daten von einem "users"-Nutzer kopiert werden ( = Mindestanforderung für die grundlegende Einrichtung)​

​

Darüber hinaus kommen hier noch Daten von diversen externen Quellen dazu (hauptsächlich Dokumente, bei ausreichend Platz auch Fotos). Die 2 TB wird also die este Intanz, wo alle wichtigen und relavanten persönlichen Daten gelagert und zusammengeführt werden.​

(Bestenfalls auch wieder gespiegelt auf 1TB unter Nutzer "x-worf", während "2TB" die Referenz bzgl. Löschungen wäre. Aber das ist eine viel spätere Baustelle.)​

• Die 4TB soll ein erstes "backup" sein, wo die Daten von 2TB (Datenplatte) hinkopiert werden sollen, aber auch, wo Backups von anderen Geräten zusammenlaufen und auch noch die Fotosammlung ihren Platz hat. Diese Platte soll im Gegensatz zu 2TB nur bei Bedarf gemountet werden. Es ist die einzige SSD, die ich bei Bedarf ausbauen kann und somit auch mal gewechselt werden könnte. (Die anderen sind von Komponenten verdeckt)

Die gesamte 4TB soll auf eine externe 4TB gesichert werden und zukünftig verschlüsselt in einer Cloud.​

Externe Quellen sind derzeit:

• GOS-Tablet
• GOS-Handy
• iPad (vermutlich übern Umweg WinOS samt iMazing)
• diverse Datenträger, die zuletzt unter WinOS genutzt wurden.
• zukünftig Cloud (vermutlich StorageShare [kollaborierend] und StorageBox [Einzelbackup] samt Cryptomator)

Diese Quellen sind aber auch mögliche Ziele, für z.B. ausgewählte persönliche Daten/Verzeichnisse, die ich auf den Geräten & Cloud vorhalten möchte, oder auch mal für den Fotodrucker in der Drogerie, oder um z.B. steuerrelavante Daten auf einem WinOS zu verarbeiten.

---

Mounten

Die Art und Weise, bzw. der Ort/Pfad, wo gemountet wird hat keinen Einfluss?

Denn hier frage ich mich auch, ob ich alles richtig mache, bzw ob die GUI wirklich alles richtig verarbeitet, oder ich nicht doch gleich über die Konsole arbeiten sollte. Allerdings möchte ich gerne auch verstehen welche Kommandos ich abtippe.

Ich verstehe auch noch nicht, warum die 1TB einmal mit "fedora" und einmal mit "verschlüsselten Laufwerk" doppelt aufgeführt wird.

Wie die 2TB und 4TB gemountet werden ist im Anhang zu sehen (hoffe ich).

Die "Systemplatte" ist mit LUKS verschlüsselt. Die anderen beiden bisher nicht.
(Bin mir nicht sicher, ob ich das brauche. Den einzigen Schutz den ich hier sehe ist, ist bei Einbruch von "Bösen". Die "Guten" können das System eh keyloggen, wenn gewollt. Dafür bin ich aber nicht ausreichend paranoid.
Aber grundsätzlich habe ich bei Backups "unverschlüsselt" ein besseres Gefühl bzgl Software- und Anwendungsfehler)

---

Benutzergruppen & -rechte
Durch meine Namensgebung habe ich das selbst etwas durcheinander gebracht, aber vor allem auch, weil ich das Root-PW bisher noch nicht anweden musste (und ich daher nichtmal prüfen konnte, ob es richtig notiert ist).
Derzeit: Nutzer "Admin" = "user", Nutzer "x-worf" ="users".

Ich weiß bisher auch gar nicht, wie ich als "root" arbeiten kann. Wenn "user" mit "sudo" reicht, ist das für mich auch ok.

Die Unterscheidung der Anzeigen "1001", "1000" und "10" verstehe ich noch nicht ganz. Die gibt es getrennt je Nutzer als auch Benutzergruppen, weil sie sozusagen das Zugriffslevel einer Gruppe bzw. eines Nutzers anzeigen?
(Ich frag so "doof", weil ich es für grundlegend wichtig halte)
(Ich glaube ich muss mir das mal als Matrix visualisieren)

Bei Rummeluff (im ersten Codeblock, Zeile 4) steht "gid=100(users)". Ist die "100" ein Typo und es fehlt eine "0", oder was bedeuted die "100"? Ich dachte es gibt nur "wheel = 10", "user = 1000" und "users = 1001".

Randproblem:
Offenbar verarbeitet die GUI (Einstellungen -> "Benutzer") Namensänderungen nur teilweise. Es ändert schienbar nur die "uid". Ich hatte meinen Namen (hier jetzt als "x-worf" angezeigt) zu "nutzer" ändern wollen. Führt das zu technischen Problemen, (oder ist einfach nur potenziell verwirrend)?
Oder ist das richtig so und ich verstehe etwas nicht?

admin@Terra:~$ id
uid=1000(admin) gid=1000(admin) Gruppen=1000(admin),10(wheel) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Warum taucht unter Gruppen nicht auch "1001(x-worf)" auf? Weil ich die Konsole als admin-Nutzer ausführe?
Kann man sich eine Übersicht aller UIDs, GIDs und Gruppen anzeigen lassen?

admin@Terra:~$ id nutzer
uid=1001(nutzer) gid=1001(x-worf) Gruppen=1001(x-worf)
admin@Terra:~$ id admin
uid=1000(admin) gid=1000(admin) Gruppen=1000(admin),10(wheel)

Beispielbild (Dokumente von x-worf kopiert auf 2TB)

Wenn ich euch jetzt richtig verstehe muss ich zusehen, dass alle Daten (entsprechend der oben aufgeführten Ablageorte, so wie Quellen und Zielorte), die ich verarbeiten möchte (lesen, schreiben, löschen), die gleiche Gruppe haben.

Wenn ich Pummeluffs Hilfe richtig verstehe, kann das alles nur gewährleistet sein, wenn ich alle Nutzer als "users" einrichte, weil somit alle erstellen Dateien & Ordner ebenfalls der Gruppe "users" zugehören.
Falls ich dann doch mal Daten von "user" (mein "Admin" Home-Verzeichnis) zu "users" (Ablage auf 2TB) kopieren möchte, dann muss ich die Daten jeweils neu zu "users" degradieren.

Muss ich das für jedes Zielverzeichnis machen?
(sind ja in Summe doch Einige und immer mal Neue. Vermutlich kein Problem, sobald mans kann und verstanden hat.)

Aber müsste ich nicht alle diese individuellen Anpassungen umschiffen, wenn ich "passend" mounte, die Partitionen (in meinem Fall gesamte Laufwerke) dadurch (?) passende Rechte bekommen und Nutzer beim Anlegen "passende" Recht gebe?

---

EDIT1:
https://wiki.ubuntuusers.de/Benutzer_und_Gruppen/#Nummerierung-der-UID-GID
id = aktueller Benutzer

Die Sache mit den Benutzergruppen hab ich anscheinend noch nicht verstanden...

less /etc/group

wheel:x:10:admin
users:x:100:
admin:x:1000:
x-worf:x:1001:

x-worf = fürs Beispiel hier geändert, hat eigentlich noch den ursprünglichen Namen.

/etc/adduser.conf

scheint es bei Fedora 41 KDE nicht zu geben. Finde ich in Dolphin zumindest nicht.

---

setgit
Soweit ich gehört habe ist unter Linux alles eine Datei...

Das heißt die setgit-Nummern sind dann eine andere Art der Verwaltung der uid/gui je Gruppe, die dann per Zahlen definiert wird?
Oder ist das dann die Rechteverwaltung je uid/gui und Gruppen?
Oder ist hier mehr der Bezug zu den Pfaden bzw. Mountpunkten?

---

Wenn ich das jetzt bisher richtig verstehe, ist die Rechteverwaltung unter Linux restriktiver und nicht so einfach, wie unter WinOS, da dies der Sicherheit bzgl mehrere Benutzer und Fernzugriffen dient.

 

[Pummeluff]

Die Art und Weise, bzw. der Ort/Pfad, wo gemountet wird hat keinen Einfluss?

Nein, es gibt den Filesystem Hierarchy Standard, in dem beschrieben ist, welches Verzeichnis wofür da ist. Beim Mounten gilt:

• Wechseldatenträger, z.B. USB-Sticks, SD-Karten werden nach /media gemountet.
• Temporär eingebundene Dateisysteme, z.B. Backup-Platte mount man nach /mnt.
• Dauerhaft eingebundene Festplatten mountet man dahin, wo man sie benötigt.
• Datenträger, die vom Desktop Environment, z.B. Gnome eingebunden werden, mounten die DEs nach /run/user/, da keine Root-Rechte dafür notwendig ist.

Denn hier frage ich mich auch, ob ich alles richtig mache, bzw ob die GUI wirklich alles richtig verarbeitet, oder ich nicht doch gleich über die Konsole arbeiten sollte.

Letzteres. GUIs erscheinen einfacher, verschleiert aber viel. Tatsächlich ist die Konsole logischer und eindeutiger und im Endeffekt bei sehr vielen Aufgaben einfacher.

Die Unterscheidung der Anzeigen "1001", "1000" und "10" verstehe ich noch nicht ganz.

Wir mal einen Blick in die passwd: cat /etc/passwd. Da stehen Deine ganzen User drin. Die Nummern sind die uids (User-IDs). Dabei gilt:

• UIDs > 1000: "Menschliche Nutzer", d.h. reale Personen
• UIDs < 1000: Technische Nutzer, unter denen diverse Programme/Services laufen.

Definiert ist das in cat /etc/login.defs.

Die Gruppen stehen in cat /etc/group (klick)

Das heißt die setgit-Nummern sind dann eine andere Art der Verwaltung der uid/gui je Gruppe, die dann per Zahlen definiert wird?

Die gids (Group-IDs) beginnen bei normalen User-Gruppen normalerweise bei 100 (nein, da fehlt keine 0).

uid=1000(admin) gid=1000(admin) Gruppen=1000(admin),10(wheel) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Einen Nutzer "admin" zu nennen, der kein Admin ist, ist Blödsinn. admin ist hier ein ganz normaler Nutzer, für den automatisch eine gleichname Gruppe mit selber ID, d.h. uid=gid, angelegt wurde. Zusätzlich ist der Nutzer noch in der Gruppe wheel, die dazu berechtigt, mit sudo Befehle unter einem anderen Nutzer (u.a. Root) ausführen zu dürfen. Die Kontext-Einträge kannst du ignorieren. Die gehören zu SELinux.

Wenn ich das jetzt bisher richtig verstehe, ist die Rechteverwaltung unter Linux restriktiver und nicht so einfach, wie unter WinOS

Ganz im Gegenteil. Windows nutzt per default ziemlich granulare ACLs. Die Windows-Rechteverwaltung ist um einiges komplexer. Und wenn du mal in Multi-User-Umgebungen im Mixbetrieb zwischen Windows- und Linux gearbeitet hast, dann freust du Dich über die Einfachheit der Linux-ACLs (die wir hier noch nicht mal verwenden).

Warum taucht unter Gruppen nicht auch "1001(x-worf)" auf?

Weil niemand den User admin der Gruppe x-worf zugeordnet hat.

Das heißt die setgit-Nummern sind dann eine andere Art der Verwaltung der uid/gui je Gruppe, die dann per Zahlen definiert wird?

Nein.
Linux-Rechteverwaltung, Setuid + Setgid+Sticky-Bit.

Generell find ich es klasse, dass du Dich in die Thematik einarbeiten willst. Allerdings denkst du noch etwas zu kompliziert. Normalerweise hat jeder Befehl (nur) eine Funktion/Aufgabe, nicht mehr.

Derzeit kapiere ich nichtmal wie ich in der Konsole in der man page navigiere.

Dazu hilft es, wenn man sich etwas mit Vim (meiner Meinung nach der beste Editor) beschäftigt. Am Anfang ist das purer Masochismus. Ich hab mich 2 Jahre lang damit rumgequält. Seitdem finde ich jeden anderen Editor schlecht. Ist vielleicht etwas Stockholm-Syndrom dabei.

Lernen kann man VIM mit Vim Adventures.

 

[Donnerkind]

Grundsätzlich hilft es mir, wenn ihr gute Quellen zu Hilfen mitpostet, damit ich die Beiträge besser verstehen kann.

Deshalb gebe ich bei Leuten, die noch ganz am Anfang stehen, gern noch ein paar erklärende Sätze dazu. Denn was hilft es mir oder der anderen Person, wenn ich einen Programmnamen rein werfe ohne zu erklären, wozu das gut ist.

Ich verstehe auch noch nicht, warum die 1TB einmal mit "fedora" und einmal mit "verschlüsselten Laufwerk" doppelt aufgeführt wird.

Das „verschlüsselte Laufwerk“ ist das LUKS-„Gerät“ und „fedora“ erscheint, nachdem das Luks geöffnet worden ist.

Aber grundsätzlich habe ich bei Backups "unverschlüsselt" ein besseres Gefühl bzgl Software- und Anwendungsfehler)

Ich benutze seit vielen Jahren LUKS sowohl für Systeme als auch Backups und hatte noch nie ein Software-Problem, das die Verschlüsselung kaputt gemacht und dadurch zu Datenverlust geführt hätte. Und eine Gefahr durch Anwendungsfehler hast du mit und ohne Verschlüsselung gleichermaßen.

Ich weiß bisher auch gar nicht, wie ich als "root" arbeiten kann. Wenn "user" mit "sudo" reicht, ist das für mich auch ok.

Als root „arbeiten“ sollte man allgemein nicht. Es gilt das Prinzip der geringsten nötigen Berechtigungen. Die Ausnahme bilden Arbeiten direkt am System, z.B. die Einrichtung von Systemdiensten. Für diesen Zweck habe ich tatsächlich immer ein getrenntes Terminal offen, auf dem root dauerhaft an ist. Das wird oft nicht empfohlen, es bedarf Selbstdisziplin, dort wirklich nur dann Befehle auszuführen, wenn es notwendig ist. Aber ich bin einfach zu faul, ständig sudo zu tippen. Ich nutzte sehr viele Jahre Gentoo, da hatte ich sudo nicht einmal installiert.

Dazu hilft es, wenn man sich etwas mit Vim (meiner Meinung nach der beste Editor) beschäftigt.

Ich liebe ja vim, verbringe fast meinen gesamten Computeralltag darin. Aber dafür ist es hier vielleicht noch etwas früh. 😅 Es genügen vielleicht erst einmal die wichtigsten Tasten für manpages. Die benutzen das Programm less, um längere Texte anzuzeigen (ein sog. Pager). Und hier gibt es ein Standard-Tastenschema, das sich auch in sehr vielen anderen Unix-Programmen etabliert hat, eben inspiriert durch vim, weil es sehr tippfreundlich ist. Selbst Okular, der PDF-Betrachter von KDE, hat eine vi-inspirierte Tastenbedienung eingebaut.

h = Tastenhilfe anzeigen
q = beenden
j/k = eine Zeile runter/hoch
f/b = Seite runter (foward)/hoch (back)
d/u = halbe Seite runter (down)/hoch (up)
/ = Suche
? = Rückwärtssuche (weil auf engl. Tastatur Umschalt + / ein ? ergibt)
n = letzte Suche fortsetzen
N = letzte Suche in die andere Richtung fortsetzen

Warum hjkl? Das ist die „home row“, also der Bereich, wo man im „Leerlauf“ die Finger auf der Tastatur parkt. Sie sind also am schnellsten und einfachsten erreichbar, und werden deshalb für die grundlegende Navigation genutzt. Historisch entstand der Urvater „vi“ auf einem System, bei dem die „Pfeiltasten“ auf genau diesen vier Buchstaben lagen. Siehe dazu ein Foto auf Wikipedia.

 

[X-Worf]

Ich lese mich gerade in eure Antworten ein, aber per Suche habe ich gerade keine Antwort gefunden.

Was hat das "-" zu bedeuten und warum sind die Inhalte unterschiedlich?
bspw. "subgid" und "subgid-"
(Beides aus dem Nutzerprofil "admin" aufgerufen)

 

[rgbs]

Was hat das "-" zu bedeuten

Das ist ein Backup.
Siehe auch:
https://manpages.ubuntu.com/manpages/trusty/man5/subgid.5.html
Aber so wie ich das sehe, reibst Du dich an den falschen Stellen auf, z.B. der (entschuldige wenn ich es so direkt sage) Unsinn mit den zwei Usern, wenn Du als einziger an dem System arbeitest.

Gruß
R.G.

 

[X-Worf]

Danke! Die Vermutung hatte ich Aufgrund des Inhaltes schon. Aber gut es genau zu wissen.

---

Die Annahme ist, dass es grundsätzlich sicherer sei einen Nutzer ohne "Systemverwalter"-Rechte im Alltag zu nutzen.

NutzerA (hier "admin") mit Systemverwalterrechten (also mit der Möglichkeit "sudo" nutzen zu können, wenn ich das richtig verstehe.) Für reine Systempflege bei Bedarf.
NutzerB (hier "nutzer" bzw. "x-worf") fürn Alltag.
NutzerC (hier "drei") zum Testen angelegt (zukünftig vielleicht Projektbezogene Nutzer, oder zusätzliche Nutzer für Personen)
[siehe Anhänge]

Grundsätzlich ist auch möglich, dass auch andere Personen den Desktop mit eigenen Nutzern benutzen werden. Und dann wäre es schon gut, die eigenen Dateien schützen zu können (zumindest maximal Leserechte).
Und ansonsten ist es, abgesehen von der besagten Annahme, so, dass ich auch einfach gern ausprobiere und rumspiele.

---

Über die GUI (siehe Anhang) kriege ich es auch hin, dass der obengenannte "Dokumente"-Ordner ( von Nutzer "x-worf) auf Laufwerk "2TB" von allen derzeit angelegten Nutzerprofilen genutzt werden kann. Morgen werde ich mal testen, wie es sich mit neuen Nutzer "vier" verhält.

Danach werde ich testen, wie ich Ordner den Gruppen Gruppen den Verzeichnissen hinzufügen kann, damit "vier" dann z.b. nur lesen kann.

Wenn ich das jetzt über die GUI lösen kann, ist das auch gut.

---

Danach wollte ich den Vorschlag aus #4 mit dieser Anleitung testen. Wobei mir noch gar nicht klar ist, ob es dazu diese Anleitung braucht, oder ob ich einfach "/persönlicheDaten" anlegen kann. Aber vermutlich ist das dann grundsätzlich erstmal nur dem Nutzer mit seiner Gruppe zugeordnet.