how to fix "Sorry, that page doesn't exist"

[xpalm]

Today my Synology can't login in DSM!!! First, I named it as synology_A. There is another Synology it works well,named it as synology_B.
synology_A info:
Product:DS3617xs
Version:DSM 6.1.5-15254 Update 1
bootloader:DS3617xs 6.1 Jun's Mod V1.02b

Then I telnet in Synology

telnet  x.x.x.x 

sudo -i

#login in as root, password is same as admin.

Then I compare synology_A and synology_B's Process.I find  synology_A has many [defunct] process.

root@synology_A:~# ps -ef | grep cgi
root      2948 10340  0 Mar20 ?        00:00:00 [synoscgi_______] <defunct>
root     10280     1  0 Mar19 ?        00:00:08 /usr/syno/sbin/synocgid -D
root     10340     1  0 Mar19 ?        00:00:26 synoscgi
system   10470 10340  0 Mar19 ?        00:00:00 synoscgi
system   29109 10340  0 17:28 ?        00:00:00 synoscgi
root     29180 29148  0 17:30 pts/5    00:00:00 grep --color=auto cgi
system   31659 10340  0 Mar20 ?        00:00:00 synoscgi
system   31834 10340  0 Mar20 ?        00:00:00 synoscgi
system   31924 10340  0 Mar20 ?        00:00:00 synoscgi

Kill the parent process:

root@synology_A:~# kill -9 10340

root@synology_A:~# ps -ef | grep cgi
root     10280     1  0 Mar19 ?        00:00:08 /usr/syno/sbin/synocgid -D
root     29205 29148  0 17:30 pts/5    00:00:00 grep --color=auto cgi

Then I start up the process 'synoscgi'

root@synology_A:~# synoscgi
synoscgi: error while loading shared libraries: /lib/libsynoshare.so.6: invalid ELF header

Hahahaha,the 'libsynoshare.so.6' is a invalid ELF header.

I use shell compare synology_A and synology_B's Directory '/lib' I find there is two file is different!.

 

synology_A:

fc6a81a0cef83cc98e7af02e068646ec  ./libsynoshare.so.6
657ad98f8a46e0961804b3ad69ff257e  ./libsynopkg.so.1

synology_B:

8efad47899b4eeaaccebb6efb5cf8ddc  ./libsynoshare.so.6
5bb625ce2b7193e3a2cc3637cd33c7ec  ./libsynopkg.so.1

Ok,Try to copy synology_B's file to synology_A.

root@synology_A:~# scp root@x.x.x.x:/lib/libsynoshare.so.6 /lib/libsynoshare.so.6
root@synology_A:~# scp root@x.x.x.x:/lib/libsynopkg.so.1 /lib/libsynopkg.so.1

Start the process,it works!:

root@synology_A:~# synoscgi
Copyright (c) 2003-2018 Synology Inc. All rights reserved.
Usage: synoscgi (Version 15254)
        --help: this help
        --mode: scgi|apid (required) run as synoscgi or synoapid
        scgi related params:
        --idle-child={childNumber} (optional, default: 10) max idle child number
        --max-child={childNumber} (optional, default: 65535) max child number
        apid related params:
        --conf (required) apid config realpath

Then Reboot it!        

root@synology_A:~# init 6

Finally synology_A comes back to life! I can login again.

Note:
1. The above two files you can ask someone to send to you.
2. You can test let /lib/libsynopkg.so.1 /lib/libsynoshare.so.6 have no write authority like this:
    chmod u-w /lib/libsynopkg.so.1
    chmod u-w /lib/libsynoshare.so.6
   I have not test above.
3. You can use scp \ wget \ curl to download files into Synology.  Or use usb storage mount or use Samba (Samba is also working) 

4. If you have not enabled telnet or ssh server, you can't login in. You can Use 'Linux SystemRescue' iso write to usb storage to bootloader into  SystemRescue, then copy two files into Synology's filesystems

Edited March 27, 2018 by Polanskiman
Added proper code tags for readability

[Niklaus]

I have two comments on this as it also happened to me.

 

You can also recover the faulty library files from the PAT file that you can download from the synology site. I used 7-Zip to uncompress the PAT file first and then uncompress the hda1 file inside the PAT.

 

I saw this problem being blamed on the debian chroot package but I can not be sure of that.

[Polanskiman]

@xpalm Next time please use code tags available to you in the editor toolbar . Your post in unreadable as is. Also please make an effort with spelling.

I will edit it this time.

[xpalm]

On 2018/3/27 at 11:10 AM, Polanskiman said:

@xpalm Next time please use code tags available to you in the editor toolbar . Your post in unreadable as is. Also please make an effort with spelling.

I will edit it this time.

thx

[xpalm]

On 3/26/2018 at 5:49 PM, Niklaus said:

I have two comments on this as it also happened to me.

 

You can also recover the faulty library files from the PAT file that you can download from the synology site. I used 7-Zip to uncompress the PAT file first and then uncompress the hda1 file inside the PAT.

 

I saw this problem being blamed on the debian chroot package but I can not be sure of that.

have you try this method  ?:

chmod u-w /lib/libsynopkg.so.1
chmod u-w /lib/libsynoshare.so.6

or  set SUID 

[newbier]

Hi xpalm, it's really helpful. It solved my issue. Thanks a looooot!

 

Product:DS3617xs
Version:DSM 6.1.5-15266 Update 1 (yes, the least DSM version)
bootloader:DS3617xs 6.1 Jun's Mod V1.02b

 

But. I noticed, in my case, each time, when I upload photo (via DS Photo or Moments), trigger the thumbview process backgrounds, then there will be big chance to make me encounter this issue again..., anyway I can recover it by the simple WorkAround you provided.

 

I'm still wonder what's the root cause for this issue. if anyone suffered similar issue like me?