Probleem met admin-account in Photostation

[Martin M.]

Als ik probeer in te loggen in Photostation m.b.v. het admin-account en het admin-wachtwoord, dan krijg ik de volgende boodschap: Uw gebruikersnaam of wachtwoord is ongeldig. Probeer het later opnieuw. Ik kan echter wel inloggen via Disk Station Manager met het admin-account en bijbehorend wachtwoord, dus de combinatie van admin-account en wachtwoord klopt. Als ik het probeer via de DS Assistant en Photo Uploader, dan krijg ik ook een foutmelding over het admin-account. Met andere accounts dan het admin-account lukt het wèl om in te loggen in Photostation. Het uit- en aanzetten van Photostation in de DS manager geeft geen verbetering.
Ik maak gebruik van DS2.3-1157 op een DS109. Zie ik iets over het hoofd of is er echt iets mis? Iemand een idee?

Groetjes,
Martin.

[wizjos]

Martin,

Vreemde zaak... Ik heb eens voor je gekeken wat er zoal gebeurt als je je aanmeldt als Admin:
- via /usr/syno/synoman/phpsrc/photo/login.php wordt de login afgehandeld..
- de resultaten van je invoer worden ge-'post' naar /blog/login.php (action="/blog/login.php"). Bestaat deze directory nog?
- in /usr/syno/synoman/phpsrc/blog/login.php wordt de volgende code doorlopen:

Code: [Selecteer]

$commend = "/usr/syno/bin/synoautoblock --deny "".$_SERVER['REMOTE_ADDR'].""";
@system($commend, $retval);
$commend = "";
if ($retval == 1) {
$login_result['success'] = 'login_noprivilege';
//if username is ADMIN
} else if (strtoupper($_POST['username']) == "ADMIN") {
if(SYNOBLOG_LOGIN_ValidateAdmin()) {
$login_result['success'] = TRUE;
$commend = "/usr/syno/bin/synoautoblock --reset "".$_SERVER['REMOTE_ADDR'].""";
} else {
$login_result['success'] = 'login_error';
$commend = "/usr/syno/bin/synoautoblock --attempt "".$_SERVER['REMOTE_ADDR'].""";
}
Wat gebeurt hier:
- eerst wordt gekeken of er een autoblock op het ip-adres van kracht is. Als dat zo is dan wordt de melding 'login_noprivelege' afgegeven. ('U bent niet gemachtigd om deze dienst te gebruiken.') Is er een autoblock op je IP van kracht?
-Vervolgens wordt gekeken of gebruiker 'admin' inlogt. Als dat zo is, dan wordt de funtie SYNOBLOG_LOGIN_ValidateAdmin(), verderop in ditzelfde bestand, aangeroepen. Dit gebeurt via de systeemopdracht /usr/syno/bin/synoauth admin ".escapeshellarg(stripslashes($_POST['passwd']))
Ter test zou je dit op de prompt kunnen uitvoeren ( /usr/syno/bin/synoauth admin jouwpassword ). Als hier geen reactie op teruggegeven wordt klopt het password. Ander krijg je een melding: 'synosubox.c:85 Password is not matched.'.

Persoonlijk denk ik, gezien je verhaal, in de richting van dit ip-block. IP-blocks kun je via de DSM bekijken en verwijderen.

Succes!

Wizjos

[Martin M.]

Hé Wizjos,

Bedankt voor je snelle reactie.
Ik heb het e.e.a. naar aanleiding van jouw verhaal bekeken. De directory blog met daarin login.php bestaat nog steeds. Ik heb via DSM naar evt. geblokkeerde IP's gekeken, maar in de lijst staat niets (Automatische blokkering staat bij mij aan; ik neem aan dat je dat bedoelde). Verder heb ik de test met het commando synoauth uitgevoerd. Ik heb eerst expres een verkeerd wachtwoord ingetypt om te controleren of de foutboodschap kwam (en dat was zo). Daarna heb ik de juiste combinatie ingetypt en daarop kwam geen reactie.
Ik heb om het verhaal met een evt. geblokkeerd IP uit te sluiten even een ander IP-adres in mijn DS gezet. Maar dat veranderde niets aan de situatie. Ook dan kon ik nog steeds niet met mijn admin-account in Photostation inloggen...  

Gr,
M.

[wizjos]

Martin,

Ik bedoelde idd. de automatische blokkering. Vreemd! Dan moet het password dus kloppen... Eens zien, aannemende dat dan de call naar synoauth goed verloopt maar eens kijken bij het verdere...
De functie SYNOBLOG_LOGIN_ValidateUser() wordt aangeroepen. Hier zijn nog een paar mogelijkheden...
De functie ziet er als volgt uit:

Code: [Selecteer]

function SYNOBLOG_LOGIN_ValidateAdmin()
{
global $SYNOPHOTO_ADMIN_PASS;

@system("/usr/syno/bin/synoauth admin ".escapeshellarg(stripslashes($_POST['passwd'])), $retval);

if (0 == $retval) {
session_unset();
session_destroy();
session_start();
$_SESSION['admin_syno_user'] = $SYNOPHOTO_ADMIN_PASS;

SYNOBLOG_MISC_AddLog($_POST['username']." logged in from "."[".$_SERVER['REMOTE_ADDR']."]", "true", $_POST['username']);
return 1;
}
else {
SYNOBLOG_MISC_AddLog($_POST['username']." failed to login from "."[".$_SERVER['REMOTE_ADDR']."]", "false", $_POST['username']);
return 0;
}
}Als eerste valt op dat de variabele $SYNOPHOTO_ADMIN_PASS doorgegeven wordt (global $SYNOPHOTO_ADMIN_PASS;). Deze komt uit /usr/syno/synoman/phpsrc/blog/include/synoblog_conf.php. Daar kun je lezen dat het admin-password (voor de postgres db) 'hlinak3' is ($SYNOPHOTO_ADMIN_PASS = "hlinak3". Klopt dit?
Hierna wordt via synoauth het admin password vergeleken met het door jou opgegeven (en correcte) password. Als daar geen reactie uit voortkomt (if (0 == $retval)), dan wordt de originele sessie (anoniem) om zeep geholpen en een nieuwe sessie gestart waarbij de sessieparameter $_SESSION['admin_syno_user'] wordt gevuld met de variabele $SYNOPHOTO_ADMIN_PASS ($_SESSION['admin_syno_user'] = $SYNOPHOTO_ADMIN_PASS;).
Die sessievariabele wordt vervolgens gedurende de sessie gebruikt om het postgres-admin-password door te geven.
Hier kan het dus van twee kanten mis zijn: aan de ene kant zou het password in het bestand synoblog_conf.php geen hlinak3 kunnen zijn (maar wie gaat dat nu wijzigen? -> het is een vast password voor alle Syno's), of, lastiger, het adminpassword in de database is op de een of andere manier geen hlinak3 meer....
Dan zal je toegang moeten krijgen tot de database, zodat je het password kunt wijzigen... Maar ik ben bang dat je je dan tot Synology moet wenden...

Succes!

Wizjos

[Martin M.]

Wizjos,

Ik heb de synoblog_conf.php bekeken en daar staat inderdaad  '$SYNOPHOTO_ADMIN_PASS = "hlinak3" ' in. Dat klopt dus. Blijft over een mogelijke fout in de database. Nu zit ik gelukkig niet op een eiland, want meteen bij het inrichten van Photostation heb ik een account gemaakt met de optie "Instellen als beheerder". Nadat ik gisteren (22-5) ontdekte dat admin niet meer werkte heb ik er snel eentje met de welluidende naam atmin bijgeplaatst, ook met beheerder-privileges. Maar ik heb het gevoel dat ik, vanwege het probleem met het admin-account, de controle een beetje aan het verliezen ben. En dat gevoel bevalt me helemaal niet. Het probleem is overigens pas sinds kort opgetreden. Ik heb in de afgelopen week meerdere malen m.b.v. DS Assitant foto's ge-upload naar de NAS via het admin-account. Ik heb ook nog op donderdag (20-5) de nieuwste versie van de DS Assistant (1157) in gebruik genomen. Ook met deze DS A heb ik nog foto's op de NAS geplaatst via admin.
Als het probleem in de database zit, dan is de vraag hoe dat opgelost kan worden. Als die database opnieuw gecreëerd wordt bij het opwaarderen van de firmware, dan lijkt het mij beter om geen actie te ondernemen. Als dat niet het geval is, wat zijn dan de mogelijkheden?

Gr,
M.

[wizjos]

Martin,

Jammer dat 't nog niet opgelost is! Volgens mij is er dan idd. niet veel anders meer mogelijk dan dat het probleem bij de database ligt. Daar moet ik zelf even de handdoek in de ring gooien. Ik heb nog even door de postgres database zitten neuzen, maar accountinfo voor admin is daar niet te vinden. Zal wel via een commandline tool moeten. Hoe dat te doen (zonder de zaken erger te maken) is mij niet bekend.
Wat mij wel opvalt is dat als ik met phpPgAdmin (3rd-party) op postgres inlog met als user admin, dat deze geen password schijnt te hebben  

Tenzij bv. Bjorn nog een idee heeft, lijkt me dat je toch als enige optie overhoudt om een supportaanvraag bij Synology zelf in te schieten. Van afstand kunnen zij nog eens kijken en vaak dingen oplossen...

Succes!

Wizjos

[Martin M.]

Hallo Wizjos,

Ik vind het jammer dat jou inzet (nog) niet tot een oplossing geleid heeft. Jij hebt in ieder geval erg je best gedaan om het probleem op te lossen. Ik wil je daarvoor dan ook ontzettend bedanken. Ik hoop in ieder geval dat Björn het probleem in de komende week een keer op wil pakken.

Groetjes en bedankt,
Martin.

[wizjos]

Martin,

Dank voor je woorden! Is overigens ook een mooie knop voor
Ik vind het persoonlijk jammer dat ik je niet helemaal er uit kan helpen... Desondanks toch een aantal zaken weten uit te sluiten, hetgeen de oplossing van het probleem hopelijk dichterbij brengt. Wellicht dat idd. Bjorn er nog wat mee kan, maar ik vrees dat ook hij er weinig aan zal kunnen doen.

Hoe dan ook sterkte er mee!

Wizjos

[Björn]

Tenzij bv. Bjorn nog een idee heeft

Ik hoop in ieder geval dat Björn het probleem in de komende week een keer op wil pakken.

Wellicht dat idd. Bjorn er nog wat mee kan, maar ik vrees dat ook hij er weinig aan zal kunnen doen.

Ik ben bang dat ik je inderdaad moet teleurstellen..
Het lijkt of er een fout in de database geslopen is. Wacht even het antwoord van Synology af, want die weten vast hoe ze het moeten fixen.

[Arjen van den Brink]

Hallo..

Ik heb exact het zelfde probleem met mijn DS109.
Wil je mij vertellen als je contact hebt gehad met Synology hoe dit op te lossen?

Gr. Arjen

[Martin M.]

Doe ik...

Gr,
M.

[Martin M.]

Het probleem met het admin-account en Photostation is verholpen door Synology Support.
Nadat ik een Support Form ingevuld heb op 24 mei, heeft Synology op 26 mei een mailtje naar mij gestuurd met enkele suggesties. Als die suggesties niet tot resultaat zouden leiden, dan moest ik de poorten 23 (Telnet) en 5000 (DS manager) openzetten in mijn router/modem om de techneuten in de gelegenheid te stellen om de zaak in mijn DS109 te kunnen bekijken. In het mailtje worden overigens wel een paar aanwijzingen gegeven hoe je het e.e.a. aan moet pakken om die poorten in een NAT-tabel open te zetten. Ik heb daarop geantwoord dat de suggesties geen resultaat opleverden en ik de poorten 23 en 5000 opgezet had. Tevens heb ik hun het (aangepast) admin-wachtwoord gemaild. Op 30 mei kreeg ik weer een mailtje van Synology dat op 31 mei (maandag) de techneut die alles wist van Photostation de zaak zou gaan onderzoeken. Op die maandagochtend om plm. 10:30u kon ik weer met mijn admin-account in Photostation. Op 1 juni heb ik een mailtje gestuurd met daarin het verzoek om informatie over het probleem ('... wat was het probleem, waardoor werd het veroorzaakt en wat kan ik doen om het te voorkomen...'). Op 2 juni kreeg ik weer een mailtje van Synology met de mededeling dat eerst een hardware-techneut de zaak ook nog wilde bekijken. Uiteindelijk kreeg ik vandaag (3 juni) een bericht van Synology waarin stond dat ik de poorten weer dicht kon zetten. Verder stond in dat bericht dat het probleem te wijten was aan een php.ini-bestand dat nul bytes groot was en dat was fout. Ze hebben een goed php.ini bestand ge-upload waarmee het probleem verholpen was. Ze konden echter niet vertellen waardoor dat php.ini-bestand verziekt was. Als het weer optreedt, dan moet ik weer contact zoeken met Synology Support.
Dus voor diegenen die hetzelfde probleem hebben als ik had, neem contact op met Synology middels het Support Form.

Groetjes,
Martin.

[wizjos]

Allereerst gefeliciteerd dat alles weer werkt! Je kan nu je naam veranderen in synology_istof    

Verder stond in dat bericht dat het probleem te wijten was aan een php.ini-bestand dat nul bytes groot was en dat was fout. Ze hebben een goed php.ini bestand ge-upload waarmee het probleem verholpen was. Ze konden echter niet vertellen waardoor dat php.ini-bestand verziekt was. Als het weer optreedt, dan moet ik weer contact zoeken met Synology Support.
Dus voor diegenen die hetzelfde probleem hebben als ik had, neem contact op met Synology middels het Support Form.

Je zou dus ook een eigen reservekopie php.ini (locatie: /usr/syno/etc/) kunnen terugzetten (of desnoods uit de firmware extracten).

Groet,

Wizjos

[Martin M.]

Je zou dus ook een eigen reservekopie php.ini (locatie: /usr/syno/etc/) kunnen terugzetten (of desnoods uit de firmware extracten).

Inderdaad, dat was ook mijn idee. Ik heb dus een kopie van php.ini veiliggesteld. Maar toch bedankt Wizjos.

Gr,
M.

[Arjen van den Brink]

Allereerst gefeliciteerd dat alles weer werkt! Je kan nu je naam veranderen in synology_istof    

Verder stond in dat bericht dat het probleem te wijten was aan een php.ini-bestand dat nul bytes groot was en dat was fout. Ze hebben een goed php.ini bestand ge-upload waarmee het probleem verholpen was. Ze konden echter niet vertellen waardoor dat php.ini-bestand verziekt was. Als het weer optreedt, dan moet ik weer contact zoeken met Synology Support.
Dus voor diegenen die hetzelfde probleem hebben als ik had, neem contact op met Synology middels het Support Form.

Je zou dus ook een eigen reservekopie php.ini (locatie: /usr/syno/etc/) kunnen terugzetten (of desnoods uit de firmware extracten).

Groet,

Wizjos

Ik denk dat mijn probleem hetzelfde is.
Ik heb ook in de php.ini lopen rommelen om mijn joomla site beter te laten lopen.
Heeft iemand voor mij een backup van php.ini waarin ook joomla kan werken. (probleem was dat ik steeds foutmeldingen kreeg bij modules installeren ect.)
Bijvoorbaad dank.

Ps. Martin bedankt voor je plaatsing van de oplossing!