Synology WordPress 404 on Synology after restarting NAS

Each time I restart my NAS (for update reasons), I have errors 404 when trying to reach any post of my WordPress blog, until I re-set permalinks’ settings. I finally fixed it by updating my WordPress with latest Synology’s package.

Click to Read More

A long time ago, rebooting my NAS started to result systematically in 404 in my WordPress blog. I found a manual fix here: simply resetting WordPress permalinks’ settings was solving the problem… until the next reboot :(

But I never understood why rebooting my NAS was resulting in the lost of permalinks’ settings. And could find a definitive solution.

I finally took today an hour to reproduce and further investigate the problem (motivated by the shiny sun outside :p). I found that restarting only the WordPress Package was also resulting in this issue. I noticed more precisely that the .htaccess file was deleted when starting the package (not when stopping). I am sure that removing access rights on the .htaccess file for WordPress, as described here for example, would be a solution. But the not best one.

I found the best solution by accident. A long time ago, as I was interested in a version of WordPress more recent than the one available via Synology’s packages, I did a manual upgrade with the official WordPress setup. Since that time, I never did an update anymore with Synology’s Package Manager, but used the native WordPress update via its own Dashboard:

WordPress-Update

Today, I did a backup of WordPress’ installation folders and updated Synolgy’s WordPress Package. Once the update accomplished, I noticed that the .htaccess was containing information specific to Synology:

# Synology PHP
AddHandler default-handler .htm .html .shtml
AddHandler php-fastcgi .php
AddType text/html .php
Action php-fastcgi /php56-fpm-handler.fcgi
# Synology PHP

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wordpress/
RewriteRule ^index\.php$ – [L] RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wordpress/index.php [L] </IfModule>

# END WordPress

And now, when restarting WordPress, the .htaccess is not deleted anymore (and permalink’s settings are not lost). There is certainly a good explanation, that I ignore, but at least I won’t suffer 404 anymore.

And next time I update manually WordPress, I will pay attention to backup the .htaccess as specially clearly recommended here, as well as merging that .htaccess with the updated one after the update of the Permalinks’ structure:

  1. Backup your database. Read Backing Up Your Database for a detailed explanation.
  2. Backup ALL your WordPress files in your WordPress directory. Don’t forget your .htaccess file.
  3. Verify the backups you created are there and usable. This is essential.
  4. Ensure first four steps are completed. Do not attempt the upgrade unless you have completed the first four steps.
  5. Delete the old WordPress files on your site, but DO NOT DELETE

    • wp-config.php file;
    • wp-content folder; Special Exception: the wp-content/cache and the wp-content/plugins/widgets folders should be deleted.
    • wp-images folder;
    • wp-includes/languages/ folder–if you are using a language file do not delete that folder;
    • .htaccess file–if you have added custom rules to your .htaccess, do not delete it;
    • robots.txt file–if your blog lives in the root of your site (ie. the blog is the site) and you have created such a file, do not delete it.
  6. Upload the new files from your computer’s hard drive to the appropriate WordPress folder on your site.
  7. Run the WordPress upgrade program and follow the instructions on the screen.
  8. Update Permalinks and .htaccess. Update your Permalink Structure and merge the custom rules, if necessary, into your .htaccess file.
  9. Install updated Plugins and Themes. Please review the list of Plugins that work in Version 4.8. Check for Theme Compatibility with 4.8 and ask your Theme author for any new version.

Synology Synology: “DSM updating in process…” forever

I recenlty tried to update my DSM 6.1.1-15101 from pacth 3 to 4. For some unknown reasons, the update never ends which results in various “issues”. The only solution I found to exit that situation was to kill the upgrade process.

Click to Read More

Once the update started, the progress eventually appeared stuck…

Updating Synology

After 2 hours, I decided to open the admin interface (http://<MySyno>:<adminPort>) and was able to log in. But back into the Control Panel, I saw the message “DSM updating is in process…”…

DSM Updating

It would not have been a big issue if it didn’t prevent me to update any packages. Trying to do so was resulting in a popup blocking any automatique on manual installation/update. I was also unable to restart or shutdown properly the NAS for the same reason.

To solve this situation I had to kill the upgrade process:

  1. Open a SSH console using Putty to connect onto the NAS
  2. Login as administrator
  3. Enter the root mode using the command: sudo -i
  4. Kill the update processes typing the command: kill -9 $(ps aux | grep -e SYNO.Core.Ugrade |grep -v grep | awk ‘{ print $2 }’)

I was next able to update other packages… I did next restart the NAS but for some reasons, it never rebooted completed (neither detected by the Synology Assistant nor accessible via the Admin webUI). I had therefore to do a hard reboot :(

Now, although I am still unable to reboot properly or upgrade DSM, I can at least install (or update) packages, possibly to help me in backuping everything before a complete reset.

NB.: I also tried to upgrade from SSH, without success.

Using the feature auto, I got an error message:

root@Hades:~# synoupgrade –check
UPGRADE_CHECKNEWDSM
Available update: DSM 6.1.2-15132, patch type: dsm, restart type: reboot, reboot type: now

root@Hades:~# synoupgrade –download
UPGRADE_DOWNLOADDSM
New update has been downloaded

root@Hades:~# ls -la /volume1/@autoupdate
total 223684
drwx—— 2 root root 4096 Jun 16 18:49 .
drwxr-xr-x 37 root root 4096 Jun 16 18:49 ..
-rw-r–r– 1 root root 229038080 Jun 14 11:50 DSM_DS1815%2B_15132.pat

root@Hades:~# synoupgrade –check-pat ./DSM_DS1815+_15132.pat
UPGRADE_CHECK_PAT
Patch type is DSM
ErrSysAvailSize

root@Hades:~# synoupgrade –auto
UPGRADE_AUTO
New update has been downloaded
Start DSM update…
ServerUpgrade failed

Using an explicit download or the explicit path of the patch auto-downloaded, I get no error:

root@Hades:~# synoupgrade –patch /volume1/@autoupdate/DSM_DS1815%2B_15132.pat
UPGRADE_PATCH
Start DSM update…
root@Hades:~#

root@Hades:~# wget https://global.download.synology.com/download/DSM/release/6.1.2/15132/DSM_DS1815%2B_15132.pat
–2017-06-16 18:34:22– https://global.download.synology.com/download/DSM/release/6.1.2/15132/DSM_DS1815%2B_15132.pat
Resolving global.download.synology.com… 52.222.227.46, 52.222.227.228, 52.222.227.163, …
Connecting to global.download.synology.com|52.222.227.46|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 229038080 (218M) [binary/octet-stream] Saving to: ‘DSM_DS1815+_15132.pat’

100%[==================================================================================================================>] 229,038,080 10.0MB/s in 30s

2017-06-16 18:34:53 (7.23 MB/s) – ‘DSM_DS1815+_15132.pat’ saved [229038080/229038080]

root@Hades:~# synoupgrade –check-pat /root/DSM_DS1815+_15132.pat
UPGRADE_CHECK_PAT
Patch type is DSM
Check patch successfully

root@Hades:~# synoupgrade –patch /root/DSM_DS1815+_15132.pat
UPGRADE_PATCH
Start DSM update…
root@Hades:~#

Fortunatelly, in all cases, the DSM is not suck in “updating in process”