Cannot log in to DSM (Synology NAS)

synology

I think I have locked myself out from a Synology DSM Web access. When I was logged in, I removed all "granted by default" privileges, and apparenlty one of them (Desktop?) affected my administration account. Now when I get to the login page, I successfully fill username, password and 2nd verification and then I got a "You are not authorized" error (note: my IP is not auto-blocked). I have all passwords and can access the device via ssh and the data via SMB.

All I could research is to do a soft reset, but I am not sure whether this will fix privileges too and I would prefer not to destroy my current configuration.

By using ssh, is there a way I can fix the privileges to add my custom administration user to log in to DSM? I've been exploring some files on /etc with no much success.

Best Answer

Thanks to Tonny's confirmation about Desktop I was able to fix the problem, so I will share because it is a bit frustrating if this happens to you....

After successfully inserting the passwords in DSM, the error is something like this: You are not authorized to use this service. "You are not authorized to use this service."

Steps to fix the problem if you accidentally locked yourself out of the DSM Web access:

  1. You need to have ssh access, and use an administrator user. If you don't, you probably need to do a soft reset.
  2. (I am using Linux) Execute: ssh your_username@your_synology_ip
  3. cd /etc
  4. grep your_username /etc/passwd (e.g. grep administrator /etc/passwd) The answer will be something like administrator:x:1021:100::/var/services/homes/administrator:/bin/sh You are interested in your id, in the example: 1021
  5. Make a backup of the database, just in case: cp synoappprivilege.db synoappprivilege.db.org

  6. sudo sqlite3 synoappprivilege.db It will ask for your password. Insert the password of your_username (same password you used for ssh). It will prompt:

    SQLite version 3.10.2 2016-01-20 15:27:19
Enter ".help" for usage hints.
sqlite>

  7. Check tables (not strictly necessary):

    sqlite> .tables
AppPrivRule

  8. Query table (not strictly necessary):

     sqlite> select * from AppPrivRule;

    This will dump the contents of the table, which will be similar to these:

     2|0|SYNO.SDS.WebDAVServer.Instance|0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000||
 2|0|SYNO.SDS.MailServer.Instance|0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000||
 2|0|SYNO.SDS.BackupService.Instance|0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000||
 2|0|SYNO.SDS.MailPlusServer.Instance|0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000||
...

  9. The priviledge we unintentionally removed was SYNO.Desktop and will probably not be listed in the previous command. So we need to insert it (note: use your user id as obtained before with grep, in my case, 1021):

    sqlite> insert into AppPrivRule VALUES(0,1021,'SYNO.Desktop','0.0.0.0','0000:0000:0000:0000:0000:FFFF:0000:0000','','');

  10. Confirmation that everything is all right...

    sqlite> select * from AppPrivRule;

2|0|SYNO.SDS.WebDAVServer.Instance|0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000||
...
0|1021|SYNO.Desktop|0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000||

DONE! You can now log in.

After I fixed the problem I found the same solution here, but it was impossible to get from search engines on the first instance. Also, beware the insert in that link has a small mistake.

Related Question