Benutzerrechte auf Ordner & Dateien?

[X-Worf]

Beim Mounten von Windows-Dateisystemen gibst du explizit den Usernamen, die Gruppe und die Umask mit an.

Das macht die GUI wohl zumindest alles automatisch. Müsste ich mir später mal anschauen. (oder evtl. jetzt schon anlernen...)

Alle Dateien gehören dann temporär diesem einen Nutzer. Entsprechend ist die o.g. Konfiguration der Rechte sinnlos bzw. funktioniert auf diesem Dateisystem nicht. Siehe dazu auch exFAT - Dateiattribute und Sicherheit

Ich meinte eher, wie es sich mit den Zugriffsrechten unter Linux verhält, wenn ich von exFAT oder NTFS-Datenträgern Daten in mein "PAVV"-Verzeichnis kopiere, dass ich ja mit chmod auf 2775 eingestellt habe.

Spoiler: PAVV users 2775

admin@Terra:~$ sudo gpasswd -a drei users
[sudo] Passwort für admin:
Benutzer drei wird zur Gruppe users hinzugefügt.
admin@Terra:~$ sudo gpasswd -a vier  users
Benutzer vier wird zur Gruppe users hinzugefügt.
admin@Terra:~$ id drei
uid=1002(drei) gid=1002(drei) Gruppen=1002(drei),100(users),1004(projekt)
admin@Terra:~$ id vier
uid=1003(vier) gid=1003(vier) Gruppen=1003(vier),100(users),1004(projekt)
admin@Terra:~$ sudo chgrp users /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier
admin@Terra:~$ sudo chmod 2775 /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier
admin@Terra:~$

Mit Nutzer "drei" hatte ich nun testweise je einen Ordner ("Anleitungen" & "Doku Eingang") von den Datenträgern zu /ProjektAngelegtVonVier kopiert.

ausgelesen mit stat haben die neuen Ordner dort nun aber 2755.

Spoiler: stat

admin@Terra:~$ stat %a /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/Anleitungen
stat: der Aufruf von statx für '%a' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
 Datei: /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/Anleitungen
 Größe: 4096            Blöcke: 8          EA Block: 4096   Verzeichnis
Gerät: 259/7    Inode: 119538097   Verknüpfungen: 3
Zugriff: (2755/drwxr-sr-x)  Uid: ( 1002/    drei)   Gid: (  100/   users)
Kontext: unconfined_u:object_r:unlabeled_t:s0
Zugriff: 2025-02-16 22:15:30.503687341 +0100
Modifiziert: 2019-08-29 22:44:30.000000000 +0200
Geändert: 2025-02-16 22:15:30.494687144 +0100
Geburt: 2025-02-16 22:15:24.866564207 +0100

admin@Terra:~$ stat %a /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/Doku Eingang
stat: der Aufruf von statx für '%a' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
stat: der Aufruf von statx für '/ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/Doku' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
stat: der Aufruf von statx für 'Eingang' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
admin@Terra:~$

Damit fehlen doch nun aber die Schreibrechte für die Gruppe users, die die Nutzer drei und vier ja eigentlich haben sollten, oder nicht?

Bzw. warum ist das so?
Weil durchs mounten
/run/media/drei/[...]/Doku Eingang
die Rechte schon so gesetzt werden und durchs Kopieren nicht verändert werden?

Müsste ich nun direkt in /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/ mounten, oder irgendwie mit umask arbeiten?

Oder liegt es der GUI/Dolphin und ich sollte die Konsole samt cp nutzen?

Evtl. habe ich aber stat noch nicht richtig bedient/verstanden.
(Erste Anwendung eben und für mich unklare Fehlermeldung:
stat %a /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/Anleitungen
stat: der Aufruf von statx für '%a' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden)

---

Und offenbar sind Leerzeichen in Ordnern ein Problem für Linux. Das Leerzeichen muss ich dann wohl von Hand ändern, bevor ich Daten fehlerfrei verarbeiten kann.

---

Spoiler: Versuche

admin@Terra:~$ sudo mkdir /opt/projekt3
[sudo] Passwort für admin:
admin@Terra:~$ groupadd projekt3
groupadd: Permission denied.
groupadd: /etc/group konnte nicht gesperrt werden; versuchen Sie es später noch einmal.
admin@Terra:~$ sudo groupadd projekt3
admin@Terra:~$ sudo chown root:projekt3 /opt/projekt3
admin@Terra:~$ sudo chmod 2775 /opt/projekt3
admin@Terra:~$ ~]# ls -ld /opt/myproject
bash: ~]#: Befehl nicht gefunden...
admin@Terra:~$ ls -ld /opt/myproject
ls: Zugriff auf '/opt/myproject' nicht möglich: Datei oder Verzeichnis nicht gefunden
admin@Terra:~$ sudo ls -ld /opt/myproject
ls: Zugriff auf '/opt/myproject' nicht möglich: Datei oder Verzeichnis nicht gefunden
admin@Terra:~$ sudo ~]# ls -ld /opt/myproject
sudo: ~]#: Befehl nicht gefunden
admin@Terra:~$ sudo ls -l /opt/myproject
ls: Zugriff auf '/opt/myproject' nicht möglich: Datei oder Verzeichnis nicht gefunden
admin@Terra:~$ ~]# ls -ld /opt/projekt3
bash: ~]#: Befehl nicht gefunden...
admin@Terra:~$ ls -ld /opt/projekt3
drwxrwsr-x. 1 root projekt3 0 22. Feb 22:03 /opt/projekt3
admin@Terra:~$ sudo usermod -aG projekt3 funf
admin@Terra:~$ sudo usermod -aG projekt3 sechs
admin@Terra:~$ ls -ld /opt/projekt3
drwxrwsr-x. 1 root projekt3 40 22. Feb 22:16 /opt/projekt3
admin@Terra:~$ ls -l /opt/projekt3
insgesamt 8
drwxr-sr-x. 1 funf  projekt3 0 22. Feb 22:14 AV5
-rw-r--r--. 1 funf  projekt3 5 22. Feb 22:14 AV5.txt
drwxr-sr-x. 1 sechs projekt3 4 22. Feb 22:18 AV6
-rw-r--r--. 1 sechs projekt3 6 22. Feb 22:15 AV6.txt
admin@Terra:~$ ls -l /opt/projekt3/AV6
insgesamt 0
drwxr-sr-x. 1 sechs projekt3 34 22. Feb 22:19 V6
admin@Terra:~$ ls -l /opt/projekt3/AV6/V6
insgesamt 0
drwxr-sr-x. 1 sechs projekt3 282 12. Aug 2020  Privathaftpflicht
admin@Terra:~$ ls -l /opt/projekt3/AV6/V6/Privathaftpflicht
insgesamt 1340
-rwxr-xr-x. 1 sechs sechs 139161 12. Aug 2020  antrag.pdf
-rwxr-xr-x. 1 sechs sechs 731719 12. Aug 2020  download.pdf
-rwxr-xr-x. 1 sechs sechs  98574 12. Aug 2020  produktinformationen_haftpflichtversicherung.pdf
-rwxr-xr-x. 1 sechs sechs 256903 12. Aug 2020  versicherungsbedingungen_haftpflichtversicherung.pdf
-rwxr-xr-x. 1 sechs sechs 136311 12. Aug 2020  zusammenfassung.pdf
admin@Terra:~$

 

[rgbs]

Und offenbar sind Leerzeichen in Ordnern ein Problem für Linux.

Das ist bullshit.
Und sich mal mit fstab und gio mount zu befassen wäre kein dummer Plan.

Gruß
R.G.

 

[Donnerkind]

Das ist bullshit.

Leider keine sehr hilfreiche Antwort.

Leerzeichen sind natürlich kein Problem. Aber wenn du Wörter in die Shell eintippst, dann trennt diese sie an den Leereichen auf und macht aus jedem Wort ein eigenes Argument. Mit ls Hallo Welt erhält ls den Auftrag, die Dateien Hallo und Welt aufzulisten. Deshalb musst du Dateinamen mit Leerzeichen entweder in Quotes packen, oder die Leerzeichen mit vorangestelltem \ escapen: ls "Hallo Welt". Erstelle mal per GUI eine Datei mit Leerzeichen im Namen und dann geh in die Shell und tippe ls gefolgt von den ersten Buchstaben des Namens und tippe Tab. Die Vervollständigung meiner Bash fügt automatisch die \ ein.

 

[foofoobar]

Das macht die GUI wohl zumindest alles automatisch. Müsste ich mir später mal anschauen. (oder evtl. jetzt schon anlernen...)

uid=value and gid=valueSet the owner and the group of files and directories. The values are numerical. The defaults are the uid and gid of the current process.

https://linux.die.net/man/8/mount.ntfs-3g

Diese Flags werden von fast allen nicht unixoiden Filesystemen unterstützt.

"mount" (ohne weitere Parameter) zeigt auch die Flags aller montierten Filesysteme an.

 

[Pummeluff]

Fakt ist nun mal, dass man bei sudo -i mit root Rechten arbeiten kann ohne dass root aktiviert wurde.

Du kannst genauso

sudo su

verwenden. Und bist dann auch root, auch mit "deaktiviertem" Root-Konto. Das Root-Konto kannst du nicht deaktivieren. Es hat nur kein Passwort und bietet damit keine direkte Loginmöglichkeit.

Deaktivieren könntest du das Konto theoretisch mit eine dieser Methoden. Wäre mal interessant zu testen, wenn du das bei Root macht. Theoretisch sollten sudo -i oder sudo su trotzdem noch funktionieren.

admin@Terra:~$ sudo -i
[sudo] Passwort für admin:
root@Terra:~# "passwort123"

Das ist der Grund, warum ich sudo nicht mag. Im Gegensatz zum Switchuser su brauchst du hier gar kein Passwort. Damit ist der von mir genannte und von rgbs religiös verteidigte Sicherheitsgewinn wieder weg.

Das heißt, das würde passieren, wenn ich bei der Installation "Root deaktivieren" auswähle? Oder ist das wieder ein anderer Zusammenhang? (vgl. #24, Bild2)

Und in Bezug zu #25: Sollte ich bei einer Neuinstallation einfach nur den Benutzer (mit wheel) anlegen, damit die Maske (#24, Bild1) bzgl "Root-Konto" nicht mehr rot ist?

• Gruppe sudo: Der Nutzer darf Befehle mit vorangestelltem sudo ausführen.
• Gruppe wheel: Der Nutzer mit su und Eingabe des Root-Passworts zu Root wechseln.

Deaktivierung des Root-Kontos konfiguriert Dir die 1. Variante. Welche der beiden du nimmst, ist Dir überlassen.

Ich meinte eher, wie es sich mit den Zugriffsrechten unter Linux verhält, wenn ich von exFAT oder NTFS-Datenträgern Daten in mein "PAVV"-Verzeichnis kopiere, dass ich ja mit chmod auf 2775 eingestellt habe.

Die Dateirechte sind immer subtraktiv. Beim Mounten von exFAT-Dateien gibt's beim Mounten eine Defaultmaske. Die dürfte 0022 sein. D.h. von default 0777 (Verzeichnisse) und 0666 (Dateien) wird 0022 abgezogen. Damit kommst du auf 0755 für Verzeichnisse und 0644 für Dateien auf dem Exfat-Dateisystem. Kopierst du dann Dateien rüber auf Dein Shared-Verzeichnis mit 2775 wird das "logische Und" berechnet. D.h. 664 & 644 = 644 für Dateien und 2775 & 0755 = 0755 für Verzeichnisse.

 

[foofoobar]

Die Dateirechte sind immer subtraktiv. Beim Mounten von exFAT-Dateien gibt's beim Mounten eine Defaultmaske. Die dürfte 0022 sein. D.h. von default 0777 (Verzeichnisse) und 0666 (Dateien) wird 0022 abgezogen. Damit kommst du auf 0755 für Verzeichnisse und 0644 für Dateien auf dem Exfat-Dateisystem. Kopierst du dann Dateien rüber auf Dein Shared-Verzeichnis mit 2775 wird das "logische Und" berechnet. D.h. 664 & 644 = 644 für Dateien und 2775 & 0755 = 0755 für Verzeichnisse.

umask=value Set the umask (the bitmask of the permissions that are not present, in octal). The default is the umask of the current process.
dmask=value Set the umask for directories only.
fmask=value Set the umask for files only.
uid=n Set the owner for all files and directories. The default is the owner of the current process.
gid=n Set the group for all files and directories. The default is the group of the current process.

https://manpages.debian.org/jessie/exfat-fuse/mount.exfat.8.en.html

Und mit "mount" ohne Parameter kann man sich die aktiven flags anzeigen lassen.

 

[rgbs]

• Gruppe sudo: Der Nutzer darf Befehle mit vorangestelltem sudo ausführen.
• Gruppe wheel: Der Nutzer mit su und Eingabe des Root-Passworts zu Root wechseln.

Aus https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/':
"Stattdessen wird der Standardbenutzer zur Gruppe 'wheel' hinzugefügt. Mitglieder dieser Gruppe können mit dem Befehl 'sudo' Root-Rechte erhalten."

Gruß
R.G.

 

[rgbs]

Das Root-Konto kannst du nicht deaktivieren.

Aus https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/:
"Aus Sicherheitsgründen ist das root-Konto auf Fedora Workstations standardmäßig deaktiviert."
Aber es ist schon klar, Du hast mehr Ahnung als die Leute von Redhat.
Und mal so am Rande, die Gruppe sudo gibt es bei der Standard Installation von Fedora nicht.
Ich jedenfalls halte mich an die sicherheitstechnischen Vorgaben des Erstellers der Distribution, bei mir Ubuntu und da ist das Administratorkonto ebenfalls deaktiviert (das hat mit Religion nichts zu tun, sondern mit Vernunft).

Gruß
R.G.

 

[foofoobar]

Aus https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/:
"Aus Sicherheitsgründen ist das root-Konto auf Fedora Workstations standardmäßig deaktiviert."
Aber es ist schon klar, Du hast mehr Ahnung als die Leute von Redhat.
Und mal so am Rande, die Gruppe sudo gibt es bei der Standard Installation von Fedora nicht.
Ich jedenfalls halte mich an die sicherheitstechnischen Vorgaben des Erstellers der Distribution, bei mir Ubuntu und da ist das Administratorkonto ebenfalls deaktiviert (das hat mit Religion nichts zu tun, sondern mit Vernunft).

Das ist eine vereinfache Formulierung die eine Zielgruppe adressiert welche sich mit dem Thema nicht so gut auskennt.

 

[rgbs]

Das ist eine vereinfache Formulierung

Ich zähle jetzt auch mal Erbsen, eine "vereinfache Formulierung" gibt es nicht.

Gruß
R.G.

 

[rgbs]

Aus #45 von @Pummeluff

Auch falsch, man muss das Passwort des users eingeben. (ich spare mir jetzt, den getting-started-guide nochmal zu verlinken).

Gruß
R.G.

 

[foofoobar]

Das ist der Grund, warum ich sudo nicht mag. Im Gegensatz zum Switchuser su brauchst du hier gar kein Passwort. Damit ist der von mir genannte und von rgbs religiös verteidigte Sicherheitsgewinn wieder weg.

Das kann man konfigurieren:

NOPASSWD and PASSWD

By default, sudo requires that a user authenticate him or herself before running a command. This behavior can be modified via the NOPASSWD tag.

timestamp_timeout
Number of minutes that can elapse before sudo will ask for a passwd again. The timeout may include a fractional component if minute granularity isinsufficient, for example 2.5. The default is 5. Set this to 0 to always prompt for a password. If set to a value less than 0 the user's time stamp will neverexpire. This can be used to allow users to create or delete their own time stamps via ''sudo -v'' and ''sudo -k'' respectively.

https://linux.die.net/man/5/sudoers

 

[GrillSgt]

Das Root-Konto kannst du nicht deaktivieren. Es hat nur kein Passwort und bietet damit keine direkte Loginmöglichkeit.

Das ist technisch gesehen nicht korrekt und nicht ganz falsch.
Das Passwort des Kontos ist gesperrt was faktisch einem deaktivierten Konto gleichkommt. Zu erkennen am Ausrufezeichen anstelle eines "x" Eintrag in der /etc/shadow Datei:

root:!:!1975...

Alternativ könnte man das "x" in der /etc/passwd auch durch ein "!" ersetzen. Das wäre ein deaktivieren des Kontos.
Nachgesehen ist das auf Ubuntu. Bei Fedora müsste es ggfls.. jmd. prüfen. Würde kein sudo verwendet werden bzw. die sudoers Liste ist nicht korrekt konfiguriert wäre ein Aussperren aus dem System so möglich.

Deaktivieren könntest du das Konto theoretisch mit eine dieser Methoden. Wäre mal interessant zu testen, wenn du das bei Root macht. Theoretisch sollten sudo -i oder sudo su trotzdem noch funktionieren.

Ändert nichts. sudo -i bzw. sudo su funktionieren weiterhin.

 

[foofoobar]

Alternativ könnte man das "x" in der /etc/passwd auch durch ein "!" ersetzen. Das wäre ein deaktivieren des Kontos.
Nachgesehen ist das auf Ubuntu. Bei Fedora müsste es ggfls.. jmd. prüfen. Würde kein sudo verwendet werden bzw. die sudoers Liste ist nicht korrekt konfiguriert wäre ein Aussperren aus dem System so möglich.

RTFM hilft: https://www.computerbase.de/forum/t...f-ordner-dateien.2229709/page-2#post-30300111

 

[X-Worf]

Derzeit versuche ich noch herauszufinden, wie man bei Fedora 41 KDE umask dauerhaft auf Nutzerebene ändert. Man findet zwar einige Anleitungen und KI-Antworten, aber meine Erfahrung ist bisher, dass vieles bei Fedora anders geregelt wird. Oder ich durschaue die vielen unterschiedlichen Wege nicht.

Alleine den Standardkernel beim Hochfahren festzulegen ist entsprechend den Fedora-Anleitungen deutlich kürzer und einfacher, als es z.B. diverse Suchergebnisse es vorschlugen.


Aber eigentlich wollte ich nur nochmal Infos festhalten:

Bei Fedora KDE wird vor der Installation nach Name und Passwort des users gefragt, und das rot unterlegte Feld "Administrator deaktiviert" wechselt von rot zu o.k. wenn man Name und Passwort des users eingegeben hat.
Das ist meiner Ansicht nach bei Fedora KDE etwas inkonsequent geregelt, wenn man einerseits hier:
https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/ schreibt "aus Sicherheitsgründen ist root deaktiviert" aber andererseits bei der Installation das Aktivieren von root anbietet.

Gruß
R.G.

Entsprechend der zwischenzeitlichen Diskussion und ergänzt mit diesen Infos, untermauert es deine Aussage:

A root password may be set up while installing Fedora Linux, although it is now suggested to leave the root account locked and use sudo.

Dementsprechend ignoriere ich das Feld "Root-Konto" definitiv bei einer Neuinstallation. Das Installationmenü sollte/müsste für Anfänger wirklich anders sein, bestenfalls die Root-Maske nur als Option aufrufbar.

 

[foofoobar]

Derzeit versuche ich noch herauszufinden, wie man bei Fedora 41 KDE umask dauerhaft auf Nutzerebene ändert. Man findet zwar einige Anleitungen und KI-Antworten, aber meine Erfahrung ist bisher, dass vieles bei Fedora anders geregelt wird. Oder ich durschaue die vielen unterschiedlichen Wege nicht.

Man kann nicht nur im Internet suchen, sondern auch auf der eigenen Platte: (IMHO dürfte dir die selbe Datei ins Auge springen, IMHO ist es bei Redhat das selbe File wie bei Ubuntu/Mint)

sudo find /etc/ -type f -print0 | sudo xargs -0 grep -l umask
sudo find /etc/ -type f -print0 | sudo xargs -0 grep -lZ umask | xargs -0 -n 10000 less

Ergänzung (23. Februar 2025)

Dementsprechend ignoriere ich das Feld "Root-Konto" definitiv bei einer Neuinstallation. Das Installationmenü sollte/müsste für Anfänger wirklich anders sein, bestenfalls die Root-Maske nur als Option aufrufbar.

Unix tut keine mysteriösen Dinge bei der Installation die man nur bei der Installation konfigurieren kann, so wie das der Flurfunk bei Windows immer erzählt.

-l, --lock
Lock the password of the named account. This option disables a
password by changing it to a value which matches no possible
encrypted value (it adds a ´!´ at the beginning of the
password).

Note that this does not disable the account. The user may
still be able to login using another authentication token
(e.g. an SSH key). To disable the account, administrators
should use usermod --expiredate 1 (this set the account's
expire date to Jan 2, 1970).

Users with a locked password are not allowed to change their
password.
-u, --unlock
Unlock the password of the named account. This option
re-enables a password by changing the password back to its
previous value (to the value before using the -l option).

https://man7.org/linux/man-pages/man1/passwd.1.html

Oder halt per vi die /etc/shadow befummeln, geht meistens schneller als die entsprechenden Optionen aus den manpages raus zu fummeln. Der reale Sicherheitsgewinn ist eher gefühlt und psychologisch.

Das ganze bezieht sich aber nur auf handelsübliche Logins. setuid(2) und Konsorten interessieren sich einen Schießdreck für das oben genannte.

 

[Pummeluff]

Derzeit versuche ich noch herauszufinden, wie man bei Fedora 41 KDE umask dauerhaft auf Nutzerebene ändert.

https://discussion.fedoraproject.org/t/default-umask-value/71309
Global: /etc/bashrc
Nur für den eingeloggten Nutzer: ~/.bashrc

 

[foofoobar]

@Pummeluff Den Displaymanager und dessen Töchter interessieren sich nicht für die bashrc solange es keine bash ist.

 

[X-Worf]

Vielen Dank nochmal an Alle! 👍

Ich habe im Alltag zu wenig Zeit, um Alles ausführlich durchzutesten und ensprechend zu verstehen.

Meine Kernfrage war im Endeffekt, ob ich irgendwelche Rechteprobleme* bekomme, wenn ich Daten kreuz und quer (interne, externe Laufwerke, Datenquellen: Linux, WinOS, Android, iPadOS) hin und her schiebe. Das scheint nicht der Fall zu sein.
(* Rechteprobleme nicht nur auf Linux, sondern auch in anderen OS bzgl. gleicher bzw. kopierter Daten)

Der Versuch hier unter Fedora mit verschiedenen Nutzern und weniger Rechten zu starten - hier setzte dann das Thema hier an - und mit eurer Hilfe das über Gruppenberechtigungen kompatibel zu machen, klappt nur bedingt. Spätestens, wenn ich Daten von Extern zu Intern kopiere, habe ich das Problem, dass die Gruppenrechte nicht passend automatisch gesetzt sind.
Wenn ich mal Zeit dazu habe, nehme den Ansatz wieder auf und schaue mir z.B. Mountoptionen und umask nochmal genauer an, wie auch ACLs.

Fürs sytematische Rangehen fehlt mir die Zeit. Im Endeffekt bräuchte ich dafür einen Tag, bzw. eher mehr.

Aber mittlerweile weiß ich wie ich mit chmod und chown umgehen kann (größtenteils) und durchschaue die verschiedenen "Schreibweisen". Vielen Dank dafür!

Von daher kann ich jederzeit die Rechte passend ändern und habe keine Angst mehr irgendwelche Daten zu zerschießen.

Ich stelle immer wieder fest, dass hier sehr viele Infos genannt wurden, die ich beim nochmaligen Nachlesen jeweils besser verstehe. Eure Hilfen sind also hoffentlich keine verschenkte Zeit. Ich werde sie mir immer malwieder durchlesen.

Ich konzentriere mich nun erstmal auf weitere Basics für Anfängern, statt hier weiter zu spielen.


Bzgl. Root:
Mir fehlt die Zeit... und entscheidende Auswirkungen auf meine geplante alltägliche Nutzung kann ich noch nicht erkennen. Von daher fokussiere ich mich darauf, wie ich mit den GUI-Masken bei einer Neuinstallation umgehe. Letztendlich scheint es egal zu sein, ob ich ein root-PW setze, oder den Punkt überspringe. Daher folge ich einfach den Hinweis von Fedora und tue Letzteres.

Wenn ich dann doch mal was ändern möchte, habe ich hier ja auch wieder einige Infos von denen beginnend ich mich einlesen kann.

 

[rgbs]

Der Versuch hier unter Fedora mit verschiedenen Nutzern und weniger Rechten zu starten - hier setzte dann das Thema hier an - und mit eurer Hilfe das über Gruppenberechtigungen kompatibel zu machen, klappt nur bedingt.

Du solltest Dich eher fragen, weshalb Du das veranstalten möchtest.
Ein User und dann mit sudo administrative Aufgaben ausführen, fertig.

Gruß
R.G.