[gelöst]Ordner-Dateirecht auf NAS DS214 ändern

[willy4711]

Ich weiß nicht, wie ich das noch anders erklären soll.

Wenn man auf einem Gerät (hier deine DS) etwas ändern will (Du willst ja Datei- / Ordnerrechte ändern, wie ich das verstandenen habe)

Dann muss man auf diesem Gerät @ds21 als Root angemeldet sein, und nicht irgendwo anders

Und das warst du wohl noch nie.

[MSfree]

Und das warst du wohl noch nie.

Doch, er war es
Nur hatte ich geschrieben sudo bash auszuführen. Das chmod auf das betreffende Verzeichnis wurde ja auch schon erfolgreich durchgeführt, einfach mal den ganzen Thread lesen.

Der Einwurf, daß der Besitzer immer noch nicht geändert ist, ist logisch, denn chmod ändert den Besitzer nicht.

Das chown muß anschließend auf dem Linuxrechner durchgeführt werden und nicht auf der Synology.

Was Pauli sich noch mit Kerberos antun will, verstehe ich in dem Zusammenhang nicht. Klar, das kann man tun, wenn man in einem Firmenumfeld agiert, aber zuhause auf dem Heim-NAS halte ich das für totalen Overkill.

[willy4711]

Die Ursache des Problems ist, dass Synology ein spezielles System von ACLs benutzt, um die Standard-Linux-Rechte zu erweitern. Dieses ACL-System ist nicht kompatibel mit dem Standard-Dateisystem von Linux. Ich benutze hier ein Debian 9. Der Aufbau ist wie folgt:
[.......]

Also konkretes Beispiel: Man erzeugt im Linux-System ein neues File, und die angezeigten Rechte im (Debian-) Linux sind für alle 777 bzw. – rwx rwx rwx, sie entsprechen nicht den umask-Vorgaben.

der Lösungsweg, der im Zitieren beschrieben wird, erscheint mir zumindest logisch
https://www.backups.help/index.php/2018 ... te-loesen/

Das chown muß anschließend auf dem Linuxrechner durchgeführt werden und nicht auf der Synology.

In dem von mir zitierten Beitrag wird das Gegenteil behauptet.

Aber -- Ich hatte mal ne DS aber die war ohne Probleme per SMB eingebunden.

[paul1234]

also der Hauptgrund für die Ordner-Rechte/-Eigentümeränderung war, dass ich mit meinem Risotto-Bildbetrachter dort keine Datei aufrufen konnte.
Dann habe ich durch das lesen des Themas gesehen, das die original eingestellte Authentifizierung in nder DS schon die Möglichkeit des Hackens bietet. Und der dritte Grund ist der HickHack mit den UID + GID
Das sind die 3 Hauptgründe, warum ich jetzt die Änderungen wollte

gruß paul

[MSfree]

In dem von mir zitierten Beitrag wird das Gegenteil behauptet.

Der von dir zitierte Beitrag hat mit dem Problem nichts zu tun.

Aber -- Ich hatte mal ne DS aber die war ohne Probleme per SMB eingebunden.

SMB und NFS sind zwei völlig unterschiedliche Paar Schuhe.

NFS ist zustandslos und hat von Usernamen und Gruppenzugehörigkeit keine Ahnung. Dateien werden nur unter der Benutzer-ID, Gruppen-ID angelegt, die der Benutzer auf dem jeweiligen Clientrechner hat, dem NFS-Server sind die Werte völlig egal. Ich rede hier auch expizit von User-ID, das ist eine einfach Nummer, die der Linuxrechner einem Benutzernamen zuordnet. Wenn auf einem Linuxrechner ein Benutzer Hugo die User-ID 1001 hat, werden die Dateien auf dem NFS-Server mit der User-ID 1001 angelegt, nicht mehr und nicht weniger. Der NFS-Server braucht nicht einmal zu wissen, daß es einen User 1001 gibt, er braucht auf dem NFS-Sever auch nicht in der /etc/passwd eingetragen sein. Und genau das ist der Grund, warum ein chown auf der Synology fehlschlägt, auf dem NFS-Client jedoch funktioniert. Der Benutzer Hugo ist der Synology nicht bekannt.

NFS verhält sich exakt genauso wie eine Festplatte. Da darf auch jeder drauf schreiben, vorausgesetzt, das drüberliegende Verzeichnis erlaubt schreiben für jeden. Und genau das war bei der Synology nicht der Fall, aber das wurde mit chmod 777 geändert.

SMB ist immer genau an einen Benutzer gebunden, mit dessen Namen die Freigabe gemountet wird. Wird die Freigabe von Hugo gemountet, kann Heinz die Freigabe nicht benutzen. Auf einem Multiuser-OS, bei dem Heinz und Hugo gleichzeitig eingelogt sein können, wäre es ziemlich unpraktsch, wenn nur jeweils einer auf den Sever zugreifen darf. OK, man kann die Freigabe auch mehrfach mounten, was aber auch den Wasserkopf im Kernel vergrößert.

Klar, das Benutzerproblem kann man mit Kerberos und LDAP erschlagen , die Einrichtung wird aber den OP erschlagen.

[willy4711]

Der von dir zitierte Beitrag hat mit dem Problem nichts zu tun

Zumindest erschien es mir so

Der Linux-Server ist der NFS-Client, das Synology NAS ist der NFS-Server. Da die Synology-Systeme das gleiche Betriebssystem verwenden, sollte die Anleitung auch für andere Synology-NAS funktionieren.

SMB und NFS sind zwei völlig unterschiedliche Paar Schuhe.

Schon klar, wenn ich NFS auch noch nicht im praktischen Betrieb hatte. Sollte auch nur ein Wink für paul1234 sein, auf SMB umzusteigen.

Dann habe ich durch das lesen des Themas gesehen, das die original eingestellte Authentifizierung in nder DS schon die Möglichkeit des Hackens bietet

Man muss die DS ja nicht zwingend in Netz lassen. Dann reduziert sich das Problem.

[paul1234]

Hallo,

ich nehme nochmal Bezug auf den Beitrag von MSfree vom 22.02.2019 22:19:37 :
nach dem sudo bash-Befehl konntest Du per cd in das Verzeichnis auf der ds wechseln. Das geht bei mir nicht:

Code: Alles auswählen

# ssh admin@ds214
Warning: the ECDSA host key for 'ds214' differs from the key for the IP address '192.168.1.13'
Offending key for IP in /root/.ssh/known_hosts:1
Matching host key in /root/.ssh/known_hosts:2
Are you sure you want to continue connecting (yes/no)? yes
admin@ds214's password: 
admin@ds214:~$ sudo bash
Password: xyz
bash-4.3# cd /volume1 'keine Fehlermeldung
bash-4.3# cd Daten      'keine Fehlermeldung
bash-4.3# cd /Daten
bash: cd: /Daten: No such file or directory
bash-4.3# chmod 777 Daten
chmod: cannot access ‘Daten’: No such file or directory

das Verzeichnis Daten liegt direkt unter volume1

***edit**** - es hat geklappt, endlich! Danke nochmal für die Unterstützung

[frankw]

schau doch nach dem cd mit "pwd" ob du wirklich in dem Verzeichnis bist und mit "ls", was da drin ist

scheinbar bist du bereits in Daten (da kein Fehler kommt) und darin wird es nicht noch einen Ordner Daten geben