webman Zugriff funktioniert im LAN für keinen Nutzer, obwohl webman läuft

[telematoxx]

DS215j, DSM6.1
Etwas peinlich: Ich habe vermutlich alle Nutzer ausgesperrt für webman (indem ich der Gruppe "users" entsprechende Rechte entzogen habe ). Auch mein Admin nutzer (nicht der Standard Admin) bekommt im heimischen LAN die Meldung "Sie dürfen diesen Dienst nicht verwenden"). Ich habe nun 2h Recherche mit diversen Suchbegriffen hinter mir, aber keinen Lösunsgsansatz gefunden.

Was geht: Per ssh kann ich mit einem Admin Nutzer mit root Rechten arbeiten.

Was müsste mein Admin wohl tun, um diesen Fehler zu korrigieren? Welche Konfigurationsdatei muss geändert werden?

 

[Fusion]

Erstmal könntest du genau beschreiben wo du welche Rechte für die Gruppe Users entzogen hast?
Hast du die Berechtigung für "Desktop" entzogen, oder? ...

Der Admin ist eben auch Mitglied von "Users" und von einem Verbot betroffen.

 

[telematoxx]

Aus der Erinnerung heraus:
webman > Systemsteuerung > Gruppen > users > Anwendungsberechtigungen: Alle Haken entfernt.

 

[Fusion]

Das was du webman nennst wird im Allgemeinen als "DSM" bezeichnet, also die web-GUI der Synology. Dann weiß auch jeder was gemeint ist.
Das webman hast du vermutlich aus der URL im Browser abgelesen, ist die Webanwendung dazu. Ist zwar korrekt aber nicht so geläufig.

An der Stelle users > Anwendungsberechtigungen sollten überhaupt keine Haken stehen, nirgends.
Es sollten generell eigene Benutzer und Gruppen für die Arbeit benutzt werden. Die users Gruppe sollte man komplett unangetastet lassen.

Um auf dein Symptom zu kommen müsstest du aber nicht nur die Häkchen entfernt haben sondern explizit Deny/Verbieten für alle angeklickt haben.

Wie man allerdings die Anwendungsberechtigungen, insbesonder für "Desktop" damit man sich am DSM anmelden kann, per Konsole setzt weiß ich grad aus dem Stand auch nicht.

 

[Hackschnitzel09]

Hallo,
man kann über kurzes drücken der Reset Taste die Einstellungen für den Standard Admin zurücksetzen.
Ich meine man muss nur 3 Sekunden drücken, bin aber nicht sicher. Vielleicht hilft das beim googlen.

Edit: Hier der Link zur Anleitung: https://www.synology.com/en-global/...ow_do_I_log_in_if_I_forgot_the_admin_password

 

[Fusion]

Das bezieht sich normal nur auf das Passwort und andere Netzwerk-Einstellungen und Firewall, IP-Blockliste, etc. aber nicht auf Anwendungsberechtigungen.

Hier ist was zum Thema. Ist halt nicht ganz ohne (wichtig ist vorher ins /etc Verzeichnis zu wechseln, wo die synoappprivilege.db liegt).
https://forum.synology.com/enu/viewtopic.php?f=39&t=122069

 

[telematoxx]

Vielen Dank, die synoappprivilege.db scheint mir die richtige Stelle zu sein.
Erster Versuch gestern Abend hat nicht geklappt, da muss ich etwas mehr Zeit investieren (und über Benutzerrechtesystem lernen).

 

[Fusion]

Vielleicht noch ne Anmerkung dazu, was mir aufgefallen war:
Wenn der haken Deny/Verbieten gesetzt ist, fehlt die Zeile mit den entsprechenden Anwendung.
Wenn also z.B. die Autio Station verboten ist, sollte eine Suche nach diesem Eintrag erfolglos sein.
Ist kein Haken gesetzt steht eine Zeile drin, glaube es war FFFF im drittletzten Block.
Welcher Zustand es ist, wenn explizit Allow/erlaubt gesetzt ist, hatte ich vergessen zu schauen.

Hatte auch nur für den ersten angelegten Benutzer (ID 1026) geschaut und nicht nach Gruppe Users (ID 100)

 

[telematoxx]

Ich hab jetzt wieder Zugang.

Ich habe gelernt, dass bei Berechtigungskonflikten (bzgl gemeinsame Ordner) folgende Stichreihenfolge gilt: "Beachten Sie bei Berechtigungskonflikten folgende Priorität: Kein Zugriff > Lesen/Schreiben > Lesezugriff." https://www.synology.com/de-de/knowledgebase/DSM/tutorial/File_Sharing/How_to_manage_ACL_settings_on_your_Synology_NAS

In der Annahme, das Typ=1 "verweigern" bedeutet, habe ich alle Einträge des Nutzers 1026 und seiner Gruppen (100, 101, 65538) gelöscht, die den Typ 1 hatten:
sqlite> DELETE FROM AppPrivRule WHERE ID=1026 AND Type=1;
sqlite> DELETE FROM AppPrivRule WHERE ID=100 AND Type=1;
sqlite> DELETE FROM AppPrivRule WHERE ID=101 AND Type=1;
sqlite> DELETE FROM AppPrivRule WHERE ID=65638 AND Type=1

Danach hatte ich wieder Zugang.

 

[telematoxx]

Danach habe ich am Beispiel der Gruppe 65538 versucht diese Annahme (Typ=1 bedeutet "verweigern") zu verfizieren. Prinzip: Gruppenberechtigung auf dem Desktop verändern, dann Effekt im Terminal beobachten.

Für die Veränderungen: "verweigern" > "zulassen" > "verweigern" > "kein Haken gesetzt" ergibt sich folgende Beobachtung (select Befehl)
sqlite>
sqlite> select * FROM AppPrivRule WHERE App='SYNO.Desktop' AND ID=65538;
1|65538|SYNO.Desktop|||0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000
sqlite>
sqlite> select * FROM AppPrivRule WHERE App='SYNO.Desktop' AND ID=65538;
1|65538|SYNO.Desktop|0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000||
sqlite>
sqlite> select * FROM AppPrivRule WHERE App='SYNO.Desktop' AND ID=65538;
1|65538|SYNO.Desktop|||0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000
sqlite>
sqlite> select * FROM AppPrivRule WHERE App='SYNO.Desktop' AND ID=65538;
sqlite>

--> Annahme konnte nicht verifiziert werden

 

[r000633]

Ich habe heute mit einem ähnlichen problem gekämpft.
Habe lange nach einer Lösung gesucht und hin und her probiert.
Bin durch einen Hinweis im englischen Forum auf die vermeintliche Lösung gekommen, und konnte anhand einer anderen laufenden Diskstation dann verifizieren, wie es bei mir dann gelöst werden konnte.

Ich habe basierend auf dieser info hier: https://community.synology.com/enu/forum/17/post/98222?reply=332177
gearbeitet. Der Zugang per SSH zur SynoBox muss mit root rechten möglich sein, sonst funktioniert konzept hier das nicht...

Auf der Cosole wechseln wir ins /etc-Verzeichnis
Eine Sicherung der Detai synoappprivilege.db könnte später mal hilfreich sein- das beschreibe ich aber hier nicht.

cd /etc

# jetzt erfolgt der Aufruf des sqllite + connect DB-Datei:
# danach:
# Einfügen Entrag für "allgemeiner Zugang" (DSM für alle user erlauben)
# Entscheidend schweint die "2" am Anfang für den Typ zu sein
# Entscheidend ist auch die KORREKTE definition des ...0000:FFFF:0000... Blockes (5*0000:FFFF:2*0000)
# Das war bei mir nämlich in der Ursprünglichen Beschreibung im obigen link falsch.

### los gehts:
sudo sqlite3 synoappprivilege.db

sqlite>INSERT INTO AppPrivRule VALUES(2,0,'SYNO.Desktop','0.0.0.0','0000:0000:0000:0000:0000:FFFF:0000:0000','','');

sqlite> SELECT * FROM AppPrivRule WHERE App='SYNO.Desktop';
>2|0|SYNO.Desktop|0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000||

sqlite>.quit

### damit sind wir wieder auf der Console

Ab jetzt sollte das mit dem Login wieder funktionieren.

Hier noch die Deklaration der Tabelle
Table Declaration:
0 |Type|INTEGER|0| ### ich denke das beschreibt welches Objekt man nutzt 0=User;1 = Gruppe; 2= Jedermann
0 1|ID|INTEGER|0|
0 2|App|varchar(50)|0|
0 3|AllowIP|TEXT|0|
0 4|AllowIPStd|TEXT|0| ### hier unbedingt auf die richtige Anzahl und Länge der Blöcke achten !
0 5|DenyIP|TEXT|0|
0 6|DenyIPStd|TEXT|0|
0


Hoffe das hilft irgend jemandem mal weiter