Per SSH-Zugriff "Sie dürfen diesen Dienst nicht verwenden" korrigieren

[ClearEyetemAA55]

Seltsames geht in einer DS412+ vor sich..
weiss nun nicht, ob einer der lieben Kollegen ein Scherzbold ist, aber seit wenigen Tagen kann ich mich mit dem Administratorkonto nicht mehr auf die WEBGUI von DSM einlogen.
Weil alle Services rund um den Officebetrieb weiterhin laufen ist es wohl einfach noch nicht weiter aufgefallen..

SSH ok (LAN)
Drive ok (LAN)
Active Backup ok (LAN)
Windows Sicherung ok (LAN)
Webdav ok (WAN)
VPN ok (WAN)
DSM-WebGUI nicht ok

IPs (LAN) scheinen ja nun nicht geblockt zu sein -> Firewall und Blocklist blocken eher nicht
Zum Dienst DSM könnte dem (leider einzigen) Administrator der Zugriff entfernt worden sein. Passend dazu: "Sie dürfen diesen Dienst nicht verwenden"

Zwar geht SSH, aber alles was ich bisher versucht habe, läuft ins Leere.

root@DS: synouser --add syno 1 "Synology Inc." 0

---> "Sie dürfen diesen Dienst nicht verwenden" --> welcher Value fürs privilege (hier: 0) entspräche denn DSM-Zugriff?

root@DS: synogroup --add root usernames...

---> "Sie dürfen diesen Dienst nicht verwenden" ---> ??

Wüde nur ungern jetzt den kleinen Reset versuchen. Das hieße Bond wieder neu einrichten, und was weiss ich noch alles.
Kann doch auch nicht sein, dass ich die CMDs, wie im Administration CLI Guide.pdf angegeben wirklich im Ordner /usr/syno/sbin/ ausführen muss, oder?


TLDR:
Wie kann man per SSH mit root-Zugriff einem User/einer Gruppe die Berechtigung für den Dienst "DSM" zuweisen?

 

[Fusion]

sqlite3 und apppriviledge.db

https://www.synology-forum.de/showt...-im-LAN-für-keinen-Nutzer-obwohl-webman-läuft
https://community.synology.com/enu/forum/17/post/98222?reply=332177

Die Notizen die ich mir dazu gemacht habe:

cd /etc

sqlite3 synoappprivilege.db
SELECT * FROM AppPrivRule WHERE ID=1026
INSERT INTO AppPrivRule VALUES(0,1026,'SYNO.Desktop','0.0.0.0','0000:0000:0000:0000:0000:FFFF:0000:0000','','');

0|Type|INTEGER|0||0
1|ID|INTEGER|0||0
2|App|varchar(50)|0||0
3|AllowIP|TEXT|0||0
4|AllowIPStd|TEXT|0||0
5|DenyIP|TEXT|0||0
6|DenyIPStd|TEXT|0||00|Type|INTEGER|0||

 

[ClearEyetemAA55]

Ok, danke

Meine Erfahrung mit SQLite und Datenbanken allgemein geht gg null. Ich werde mich aber zurechtfinden, hoffe ich.

Habe mir jetzt erstmal von einem funktionierenden System die apppriviledge.db per scp gesichert und im DB-Browser angeschaut.
Die vergleich ich dann mal mit der apppriviledge.db des betroffenen Systems.

Kann ich die DB auch downloaden, lokal editieren und anschließend wieder einspielen? Oder muss das am Livesystem passieren?

 

[Fusion]

Kann ich dir nicht sagen. Habs noch nie offline versucht.

 

[ClearEyetemAA55]

cd /etc

sqlite3 synoappprivilege.db
SELECT * FROM AppPrivRule WHERE ID=1026
INSERT INTO AppPrivRule VALUES(0,1026,'SYNO.Desktop','0.0.0.0','0000:0000:0000:0000:0000:FFFF:0000:0000','','');

0|Type|INTEGER|0||0
1|ID|INTEGER|0||0
2|App|varchar(50)|0||0
3|AllowIP|TEXT|0||0
4|AllowIPStd|TEXT|0||0
5|DenyIP|TEXT|0||0
6|DenyIPStd|TEXT|0||00|Type|INTEGER|0||

Ich verstehe bisher:
ich greife per ´sqlite3´ auf die Datenbank apppriviledge.db zu
Aus der Datenbankstruktur AppPrivRule selektiere ich die Einträge mit ID=1026 (Administratoren)
per INSERT setzte ich für die APP ´Syno.Desktop´ die Texte ´AllowIp´und ´AllowIPStd


Komisch nur, dass in meiner funktionierenden apppriviledge.db die APP ´Syno.Desktop´nur für die ID=101 ein Datensatz existiert!? --> Annahme: Nur Blockierungen werden in der DB erfasst. Und diesen überschreibe ich mit dem INSERT. Richtig?

 

[Fusion]

ID 1026 ist der erste angelegte Benutzer bei der Einrichtung. Gruppe ID 100 (users). Gruppe 101 ist administrators.
Das INSERT setzt für diesen Benutzer die Einstellungen für den DSM Login DSM (Syno.Desktop) auf Standard.

 

[ClearEyetemAA55]

Danke

ID101 bin ich mittlerweile auch auf die Spur bekommen.

sudo synogroup --get administrators
Group Name: [administrators]
Group Type: [AUTH_LOCAL]
Group ID:   [101]
Group Members: 
0:[admin]
1:

Aber ID1026 passt schon ganz gut. Wird wie empfohlen probiert!


Was mich noch wundert:

sudo synogroup --get users
Group Name: [users]
Group Type: [AUTH_LOCAL]
Group ID:   [100]
Group Members:

gibt keine Members aus?

...
Ah, aber dafür

sudo synouser --get B
User Name   : 
User Type   : [AUTH_LOCAL]
User uid    : [1028]
Primary gid : [100]
Fullname    : [User]
User Dir    : [/var/services/homes/B]
User Shell  : [/sbin/nologin]
Expired     : [false]
User Mail   : [B@a]
Alloc Size  : [134]
Member Of   : [1]
(100) users

 

[ClearEyetemAA55]

Verstehe es nicht:

in der synoappprivilege.db war
0,1026,'SYNO.Desktop','0.0.0.0','0000:0000:0000:0000:0000:FFFF:0000:0000','',''

ich habe aus Verzweiflung nun denn Usern 100 Zugriff hinzugefügt
0,100,'SYNO.Desktop','0.0.0.0','0000:0000:0000:0000:0000:FFFF:0000:0000','',''

keine Änderung..
IE probiert, Firefox.. kein Unterschied

 

[Fusion]

Vielleicht liegt dein Problem dann doch noch woanders.

 

[ClearEyetemAA55]

Ja, möglich *grübel

Gut, es ist nur ein Knoten. Alle Geschäftsdateien sind nochmals auf den Windowsservern und tagesaktuelle Datenbestände auch auf Clients vorhanden.
Neu machen, wollte ich aber eigentlich nicht so gerne...

 

[Fusion]

Und auf das 'admin' Konto kannst auch nicht zugreifen, oder deaktiviert?
Mit einem kleinen reset würde der admin und Netzwerkeinstellungen zurück gesetzt.
Falls du für das Konto nie ein Passwort vergeben hast muss man vorher nochmal nachlesen was beim reset passiert.

 

[ClearEyetemAA55]

Die Option gibt es, richtig. Müsste dann wohl einfach einen der LANports kurz auf einen Slot am Switch klemmen, der nicht als LAG konfiguriert ist.
admin ist deaktiviert und ohne Passwort.

https://www.synology.com/de-de/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS

Halten Sie die RESET-Taste mit einer Büroklammer etwa 4 Sekunden lang leicht gedrückt, bis Sie einen Signalton hören. Lassen Sie dann sofort los.
Starten Sie Web Assistant und doppelklicken Sie auf das Feld, in dem Ihr Synology NAS angezeigt wird.
Geben Sie auf der Anmeldeseite den Standard-Benutzernamen admin ein und lassen Sie das Kennwortfeld leer. Klicken Sie danach auf Anmelden.

Aber nochmals DB..
1. Der INSERT INTO lies sich am Livesystem nicht ausführen. SQLITE3 warf Fehlermeldungen für die Eingaben

5|DenyIP|TEXT|0||0
6|DenyIPStd|TEXT|0||00|Type|INTEGER|0||

Also habe 2. ich die synoappprivilege.db offline bearbeitet und dann in /etc eingefügt.
Muss ich dann die DB nochmal irgendwie neu laden? sqlite3 ./refresh oder ähnliches?
Oder Neustart vom System?

 

[Fusion]

Warst live aber als 'root' unterwegs?
Normal sollte jeder neue Session die DB prüfen, aber ich würde vermutlich auch die DS einfach durchstarten

 

[ClearEyetemAA55]

Online hatte ich ehrlich gesagt nur "sudo sqlite3" ausgeführt

Offline habe ich die Zugriffsrechte der bearbeiteten Version von synoappprivilege.db zunächst angepasst -rw--r---r---root--root und dann per sudo mv in /etc/ geschoben

 

[ClearEyetemAA55]

Heute habe ich den kleinen Reset gemacht. Anschließend neuen Administrator erstellt und den alten 1026 zum User degradiert.
Bond noch neu eingerichtet... Firewall aktiviert und Blockliste erneuert

 

[Fusion]

Ok.

 

[ClearEyetemAA55]

Ja..

Ich danke dir trotzdem