Posts filed under ‘Synology’

MediaWiki toolbar missing after DSM update

Meh. Synology updated quite a few built-in components when updating the DSM (basically the „operating system“ of the Synology NAS boxes) from DSM 5.0 to DSM 5.1. Look at my previous articles to see what stuff broke, and how I fixed it, or at least how I found a suitable workaround for broken functionality. Let me make it clear that I’m not blaming Synology for the issues I’ve been facing; but having to fix stuff in the aftermath is a nuisance, anyway.

Okay, so here’s the most recent issue I found, and how I fixed it. When editing a page in the MediaWiki on one of my NAS boxes („zeus“), I found the toolbar was missing. Not a deal-breaker, but an inconvenience.synology-mediawiki-toolbar

In one of the articles I found by googling for „mediawiki toolbar missing“ someone suggested to turn on the Firefox web console (formerly: JavaScript console, if I remember correctly), and see if there were any JavaScript errors when editing a page. So I turned it on (CTRL+Shift+K), and indeed, an error showed up (marked in the screenshot below):


Googling for that error message, I found a short article pointing out that the „mw.loader.version“ function had been removed in a recent MediaWiki update. Thanks very much for that! 🙂 Fortunately, the article also had a link to the respective bug, and to the fix, which is here:,unified

Here’s how I applied the fix:

  1. Get on the command line, as root.
  2. In the directory where the MediaWiki is installed (/volume1/web/MediaWiki by default), either grep for „mw.loader.version“, or simply believe me that the file you need to edit is under extensions/WikiEditor/modules. So change directory there.
  3. Make a copy of the file (cp jquery.wikiEditor.js jquery.wikiEditor.js.ORIG).
  4. Edit jquery.wikiEditor.js — I’m using vi for this.
  5. Locate the line that contains the wrong function (in vi, press / and type mw.loader.version, then press Return).
  6. Change mw.loader.version to mw.loader.getVersion.
  7. Save the file, and quit the editor (in vi, this is :wq).
root@zeus:/volume1/web/MediaWiki/extensions/WikiEditor/modules> ls -l jquery.wikiEditor.js*
-rw-r--r--    1 http     http         21440 Nov 19 09:04 jquery.wikiEditor.js
-rw-r--r--    1 root     root         21437 Nov 19 08:40 jquery.wikiEditor.js.ORIG

When done, edit a Wiki page in Firefox. You might have to forcibly reload the page in Edit mode, because Firefox loves to load pages from cache. Now, the JavaScript error should be gone, and the toolbar should be back.


2014/11/19 at 09:21

SyncMe Wireless

I’ve been using Rsync Backup on my Wiko Cink Peax 2 smartphone for half a year. Two days ago, it stopped working. That is, it refused to connect to my Synology NAS (DS 214se), complaining about „no matching algo kex“. There’s a lot of discussion going on about that error on the developer’s website:

Automatic Nightly Backups for Your Android Device to Your Computer | Guysoft’s Weblog

The reason for the error: The latest operating system update on the NAS removed some old SSH ciphers that were insecure. Rsync Backup uses those ciphers. The fix would be to re-add them, so I tried that. The result was that the SSH daemon on the NAS would refuse to start up. Also, fiddling with insecure ciphers isn’t particularly secure. The real fix would be to use secure ciphers for Rsync Backup, but apparently the developer has no plans to do that. So, looking for a replacement.syncmewireless

On the Play Store, I found SyncMe Wireless. Wow, what a nice tool! Its usability is brilliant, kudos to the author!

On startup, it ran me through the process of finding the computer to back up to, by scanning the local network for Windows computers. My Synology NAS are Linux boxes, but they have SMB enabled (Synology calls that Windows File Service, fair enough), so their drives and (shared) folders show up just like Windows drives. SyncMe uses plaintext login (username/password), so I’d recommend to use it only in a safe environment, which is what I had been intending to do, anyway.

After storing the connection information, SyncMe asked to create a sync profile, which in my case is a simple backup profile for the photos. So I did that, selecting the destination folder (on the NAS), and the source folder (DCIM/Camera on the smartphone). I deselected the SyncMe option to overwrite any existing files in the destination folder, so it will copy over only new photos, which is exactly what I want.

After saving the profile, it’s now a matter of three taps to back up my photos: open the app, select the profile, run the profile. Very neat, very quick.

2014/11/14 at 12:44

Synology Network Backup failing with rsync error

On November 10, 2014, I updated my Synology NAS boxes (DS214se) to the latest DSM (DSM 5.1-5004). Next day, I found that the Network Backup jobs scheduled in Task Scheduler were failing (I’m backing up shared folders from one box to another on the LAN). Unfortunately, in the logs that can be viewed under Backup & Replication / Logs, it just says „Information … Backup task started“, followed by „Error … Failed to backup task“, without details what caused the failure. Before the DSM update, Network Backup jobs worked without issues.

Synology support seems to be overwhelmed by tickets; I filed one on Monday, and got a reply on Wednesday that they’ll take 3 to 5 business days to get back to me. (Normally, the turnaround is more like < 1 day.)

So, googling, and then logging on to the source box via SSH. (The source box is the one where the data come from, and where the Network Backup jobs are run from the Task Scheduler.) Inspecting the rsync error log unveils this:

zeus> tail /var/log/rsync.error
 Nov 11 02:00:23 (20726) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
 Nov 11 02:15:05 (20907) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
 Nov 11 02:30:05 (21091) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
 Nov 11 02:45:05 (21272) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
 Nov 12 02:00:23 (15542) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
 Nov 12 02:15:05 (15722) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]

The dates look right. In the error log, there aren’t any service is no running entries before November 11 (the day after I did the DSM update). Looks like rsyncd (the rsync daemon) isn’t running.

What the error lines don’t tell, and that took quite some more googling to find out, is that this is related to rsyncd on the target machine (the NAS where the backups end up). So I looked at the settings on the target machine, and voilà — the Enable network backup service checkbox wasn’t ticked. Ticking it, and then starting the Network Backup job manually on the source machine yielded success.


I can’t tell if it worked without the checkbox being ticked before the DSM update, or if the DSM update unticked the checkbox. In any case, Network Backup works again now, and I can sleep better again. 🙂

2014/11/12 at 09:21 10 Kommentare

Juni 2018
« Mrz    

Aktuelle Beiträge

Enter your email address to follow this blog and receive notifications of new posts by email.

Schließe dich 208 Followern an