Home button Search button Dr. Hain buttonClinic website Information for Dizzy Patients Fun Opinions (rants/raves)

Dr. Hain's Rants/Raves has helpful information about things that Dr. Hain has discovered by trial and error.

Synology 216, 412+ NAS and Synology 1813+; QNAP 563

reviewed in 2013-2016

Bottom line: These devices are not safe for a medium sized business or a home. They are not commercial grade. We right now would favor getting fiber and using a cloud backup for the backup portion. We are not sure how to deal with the need for large amounts of fast local storage.. Probably the best idea is to buy a large device (i.e. 8 slots), use a very safe RAID format (i.e. raid 10), and put in lots of memory. The QNAP device (reviewed below) works much better than the Synology devices.

Medical practices use a lot of files, and one needs a secure place for them. If one loads them into one's EMR system, then you are "locked" into that particular EMR forever. Of course, nothing is forever, and EMR companies are always going under or merging.  In other words, a prudent person puts as little data into their EMR as possible.   This also prevents "EMR bloat" -- you ask for 2 days of hospital records and end up with 500 pages of computer generated garbage and redundant copies of the same data. 

Dr. Hain thinks that small medical practices should use a distributed computer model, with several servers. The point of this is to be safe, and also to separate data (i.e. reports) from notes. The new Synology 415+ device with hardware encryption should be much faster than the older devices with software encryption, and tentatively it sounds like a great idea. There are just so many problems though. Medial practices have a LOT of data -- we are talking here about many T-bytes. Medical data is not something you want to have in the cloud as it costs too much, and even worse, who knows who is looking at your data. So encrypted NAS is pretty much your only option.

Well -- getting back to what I can directly comment on -- lets consider the Synology 412+ NAS, and related devices (we now have several 1813 NAS). These are electronic file cabinets. They are very fast, small "appliances" for file saving and backup (i.e. it doesn't need much expertise to get it going). Although a reasonable configuration costs about $1500 (box, hard-drives, UPS, gigabyte switch), compared to the cost of a business crash, it is cheap. It does not need any substantial support -- as it has a nice GUI, and doesn't require you to get "into the guts" of the Linux operating system.

The Synology box is a Linux box. Understandably, they do not provide documentation for Linux -- they don't even mention the distribution that they base it on. That's probably a good thing as users really should not be fiddling with the internals (it is horrifyingly dangerous). Still, it could use a LOT better documentation. Many critical functions are completely undocumented, and are basically trial/error.

Problems with the Synology boxes:

Synology NAS devices -- utility goes roughly as the square of # of disk drives.

The thing to know about Synology is that bigger means both more storage and faster hardware. This means that usability is not proportional to the # of disks, rather it increases with roughly the square of the # of disks. Remember that hard disks are mechanical devices, and that all mechanical devices will fail. The idea of a NAS is that you are trying to preserve your data. This is not so easy when you use mechanical drives that keep failing, and cost quite a bit each. One should PLAN to periodically replace hard drives, and one should keep a spare hard drive around to "pop in" as soon as one fails. This is bound to happen.

Another way to put this, is that the cost of the Synology devices goes up linearly with the # of drives, but the utility goes up as the square. We think that the best cost/benefit ratio would be two 1515's, but the cost for this solution is very high (think 16 hard disks -- about $1600, and 2 expensive NAS -- about $700 each).

Once you realize this, other options become a little more logical -- such as using a fast Linux server running on a small box like the "gigabyte" BRIX, and a set of two disk arrays - -ideally 4 each, that have a built in RAID. This could provide one with both a fast operating system as well as doubly redundant storage.

Synology Cloudstation -- very bad idea.

Synology bundles in with their file server a "cloud" application. In typical Synology style, it is almost entirely undocumented, and one has to "discover" what it does by trial/error.  First, lets be clear -- this is not a "Dropbox". It much less sophisticated.  There are two critical differences.

On the Synology server, you can assign "shares". There is no finer control -- if you have 1000 gig on the synology server directory,  it will attempt to "sync" 1000 gig to your home PC. Not very useful, as too much for a sync.  They need finer control. Dropbox does this.

On your synced Windows PC as well as your Synology server, you are given a different directory for uploading than downloading. You have to discover the directory yourself -- Synology does not tell you that the files you put on your PC end up in your home directory on the disk station. It does not tell you that the files you put into the synced directory on your Diskstation, end up in a directory under /users/NAME.   You have to figure this out yourself.   This lack of documentation is shameful.

As recent events in 2014 with the "synlocker virus" have shown, it is crazy to put a Synology box on a public IP address. This means that this application should be never used.

Synology Cloudsync -- a good idea done badly. Dangerous as well.

This is another installable program that essentially "offloads" the syncing process of Dropbox (or whatever cloud you like) to a synology station. You can then attach the synced share drive. This gets rid of the local computer overhead of dropbox. This is a good idea but it doesn't work. It takes a lot of processing resources, and you should keep this in mind. First, this application is hamstrung by some of the super slow hardware that Synology puts on their boxes. The "216" is an awful choice for this, as it is as slow as molasses in January. It is faster with the bigger boxes, but the core problem is that it breaks. Frequently.

Imagine -- you are depending on your sync application to keep a local copy of a large dropbox at home synced with work. Then all of a sudden, it stops working. You don't notice. A week later, you figure out that Synology (or Qnap) failed again. This happened to me.

Another thing that happened -- QNAP updated their sync program. It not only didn't work, but it didn't stop either. Imagine -- doing a local "delete" operation and having it propagate to the cloud. Awful situation.

A much better solution is to map a large ISCI drive from your NAS, and then use the dropbox application running on a PC. Setting up an ISCI drive is well documented on the web. With a little difficulty you can find the place in the Dropbox app to change the root directory. Then things are good -- the NAS does what it is good at -- file handling, and the Dropbox program does what it is good at. Of course, it costs you more money -- you have to come up with a PC that can just sit around all day and do dropbox.

Synology backup programs -- nearly useless and dangerous

There are two backup problems for file servers -- using it to backup other devices, and backing it up.

For backing up other devices -- Synology does not help you.  You have to find a suitable program yourself.  We use "Syncovery -- AKA super flexible file synchronizer" on Windows. It is very good. There are some problems here too involving logins-- the problems involve permissions of the Syncovery service-- but you can configure this program to do the job through some difficult to find parameters.

For backing up the Synology device, Synology has a several programs. Of course, you have to have a huge device to back it up.  The "time backup" application of Synology looks superficially good, but actually it is useless -- when your NAS crashes, time-backup crashes too. So what is the point. If you write everything on one drive to the other, you wear out your disks.

Strangely enough, large file system copies -- i.e. copy 1TB from this to that Synology NAS, take days (yes!). We are not sure if the NAS does this on purpose, or if it is just so slow that it really takes this long. So -- if you have a crash and need to restore for backup, plan to be down for a long time. Or better, make your backup a "mirror" device, and then just swap the pointers.

One of our major crashes was triggered by attempting to backup a synology NAS. Very dangerous.

Synology Hi-availability -- difficult

The hi-availability server has been a minefield of issues. I use the word minefield, because the problems are hidden, and gradually pop up as one proceeds down the garden path. Here they are.

Reliability issues

The Hi-availability configuration has, in our experience, crashed twice in the last 6 months. When it crashes, TWO devices go down, not one. You double your risk. This appears to be due to Synology software problems. We spent a lot of money on SSD's, and enterprise drives. They did not help. The pattern seems to be that the smaller boxes just don't work. Do not use the 4-hard-drive diskstations for this. This "feature" doesn't work.

Installation issues

1: After plugging in the "heartbeat" cable, both the passive/active server became inaccessible. I found this difficult to understand, and after it happened many many times, I asked support if a cross-over cable was needed. The answer was no. Finally, I managed to get around this by using a PC on the same switch as the two servers. I also turned off the switch I was using and turned it back on after plugging in the heartbeat connector. I don't know which of these worked, but perhaps this will help someone else. The error messages were not helpful at all.

2. Next I got a menu asking for the IP address/mask of the new cluster. I made up a new name, and I put in a vacant local IP address with our usual network mask ( The documentation was silent on what to put in, and there was nothing from users online -- so hopefully my guess was right. The lack of user feedback online is disturbing.

3. The next issue I ran into was that it refused to proceed saying that the SHR needs to be turned off on both servers. As SHR is set up by default on Synology servers, this must be a problem for most users trying to get this working. However, there is nothing online about how to do this. Again, the lack of user feedback is disturbing, and I wonder if anyone else has ever gotten this far.

4. After I cancelled the HI-AVAILABILITY installation (not knowing what to do next), then all of my networked shares became unavailable. Perhaps they were unavailable at an earlier step too -- just don't know. I rebooted both the active and passive server, and 10 minutes later I got them back again.

Synology bluetooth/wireless -- not good.

This was not a good experience. I hooked up the wireless and bluetooth to an 1813+, it connected to the network, but the whole box became a boat anchor. One could not even look at the files on the thing, although it did put up the web management page. In other words, it "looked" as if it was working, but it wouldn't do anything at all. I suppose because network connectivity was gone. It only started to work again after I removed both the wireless and bluetooth. It didn't work even when I "disconnected" the bluetooth in the software management. I was unable to "disconnect" the wireless, as the software just refused to do it (even after I removed the dongle).

The wireless/bluetooth connectivity of the Synology 1813+ box needs more work. It seems to me that wireless/bluetooth should be "built in" to these boxes. With consistent hardware, perhaps the bugs could be worked out of the software.

The Bluetooth also failed on the QNAP. Looks like this is a bad idea for a NAS.

Synology "synlocker".

Amazingly, some smart but malignant hacker wrote a version of "Cryptolocker" that specifically targets the Synology NAS. Our IT guy was adamant that the Synology NAS does not belong on any public IP address. Clearly he was right -- you don't put an appliance that contains valuable data on a public IP address. It is suicidal.

This means that nobody with important data should be using Synology remotely either. VPN is OK, but "dynamic DNS" is not.

Synology content indexing.

The idea is a good one - -why not put the processer at work indexing content. However, Synology did not come even close to getting this right. It is sooooo slow. Content indexing takes a lot of processing. These boxes don't have much of a processor.

Synology Hardware -- poorly thought out.

It is astounding that these boxes work at all given their tiny amounts of RAM. The 412+ has only 1 gig of RAM. The 1813+ has 2gig installed (wow) and an option to put in another 2 gig. I bought another memory chip, but when I tried to install it, I could not find a screwdriver that would open up the Synology box. Perhaps one has to buy one from Synology or drill out the holes. As the 1813+ is pretty much just a 412+ with 8 drives instead of 4, one might wonder why bother with the extra memory. Still, it is a lot better to have 8 drives as when one of them fail, you are better protected.

Encryption - -newer versions of Synology hardware come with "hardware encryption". So what does this really mean ? Well, if someone picks up your Synology box, and takes it home, they will not be able to read your data lacking your "encryption key". That's good. It also means that whenever there is a crash on a box that is just being used as a straight NAS (lets say every few months), nothing will work until someone who knows the encryption key, goes to the Synology diskstation admin panel, and remounts it. That's annoying, but these things do crash. Eventually of course, it is 100% certain that any hard disk will crash.

Synology support (or lack thereof) -- we think it is best to keep far away from fiddling the internals of your synology NAS.

The Synology web server, as well as almost every other aspect of the Synology software, is inadequately documented.  To get it working, requires some poking into internal config-- for example, to get the virtual host working. No documentation about this.   While it uses Apache/Mysql, the configuration files are hidden, and you have to use Putty or SSH to get to them. We would guess that if there is some sort of system update, all our modifications to get Mysql, phpmyadmin, etc working (for example), may vanish. 

Amazingly enough, the Synology help files cannot be printed. Imagine for a moment that you want to install some docker application on your Synology disk station. (not a good idea, as anything you put on a Synology box to play with will make it less likely that it's core functions will continue). Docker installation is not easy -- there are about 20 pages of documentation, complete with misspellings of common English words, how to do it embedded within the Synology help system (for 5.2). You cannot take the straightforward approach of printing off the documentation, and then going through the docker torture step by step, from hard copy. You have to run the help in one window, and the docker config in another.

The Synology linux component also seems to be explicitly unsupported, and subject to change at the whim of the Synology company - -in other words, if they "update" their linux system, then everything may stop working.

My experience with the email technical support has not been great either. In an early email interchange, when I was disturbed concerning file permissions, the tech person who responded told me that I should seriously consider buying a Windows server. A more responsible answer would be to join the active directory domain (which worked). Hope that this guy moved on to a less challenging job.

The Synology tech-support guys evidently hate providing tech support so much, that they try to send their customers to the competition. Sales must be good. Anyway, this device is a nicely engineered Linux box, but it is unsupported. Don't count on it working, and don't count on getting it fixed if it mysteriously fails either.

QNAP 563

Losing patience with the Synology boxes, I experimented with a QNAP device - -learning from past mistakes, I started with a fast box, avoiding an ARM processor, that could take a 16 gigs of memory, and had 5 slots - -the 563. I think the mistake here was in not getting an even bigger box -- an 8 slot QNAP with a fast processor and 16 gig of memory - -would be a better idea. The idea here is safety --you want LOTS of hard disk drives, that can be run in a very safe RAID configuration (5), and two SSD drives. You end up spending quite a bit on hard disk drives, but it is effective and safe. Upgrading the memory was the most stressful part - -but not too bad. I bought this box from Egghead -- who shipped me one drive that was DOA (dead on arrival). Probably a good idea with Egghead to order a couple of extra hard disk drives - -you will eventually need them anyway.

The QNAP operating system - -Qdir or something like that -- really just a customized Linux, is pretty but it doesn't seem quite as debugged as the Synology flavor of Linux. We are not sure if it would be a good idea for an business.

QNAP has the same problems as Synology, but even worse. Their "cloudstation" equivalent doesn't work either. Again, your best bet is to ignore all of the "perks" on these boxes and just use them to serve files.

Synology NAS workarounds if you want to use it as a Linux server (don't do this unless you are just playing games).

Actually, this is a really bad idea. You should not be using your Synology box as a linux server, unless you are just playing games with it. Still, perhaps you are just playing games with it. If you really want to play games with a linux server, it is far more rational to repurpose an old PC. At least it won't have it's operating system updated every month.

How to change the path for the root/admin user. (this is a bad idea however).

In order to run programs, your box needs to be able to find them. This is a little tricky, and is usually done with the PATH environment variable. Usually paths are set up in ".profile" files, which are run at login. Synology has many of these, and of course, no documentation concerning what is run when, or for that matter, any guarantee that things will still work after the next "update". The shell that synology uses is "ash".

For the current Synology DSM4 configuration, it appears that the root .profile is run after the admin profile. This causes it to overwrite whatever modifications have been made to the PATH by profiles that are earlier in the chain.

Edit the root .profile file. Comment out the PATH=, and EXPORT PATH lines (put a # in front of them). This gets rid of the overwriting.

You can also set up an "ENV" variable and run a local shell script.

How to back up your mysql database every day

Of course, one should not keep anything important in a database without backing it up. File servers have lots of space for this. Before starting however, we do NOT think it is a good idea to run a mysql server on a Synology box. Use a regular Debian box, where you can find linux configuration files where they belong.

Well anyway, I didn't figure this out for a while -- and perhaps someone will find this mistaken use of my time useful. This script was modified from http://www.backuphowto.info/how-backup-mysql-database-automatically-linux-users. The original script had a typo ("data" instead of "date")as well as it was not "tuned" for the synology linux. Still, it was mostly right.

First, test out the command line from below starting with mysqldump ...., make sure to substitute your own root password. Look to see if the file appears in your target directory (the directory has to exist, and perhaps your directory is different than mine).

second, edit /etc/crontab (suggest making a copy of it first).

15 2 * * * root mysqldump -u root -pPASSWORD --all-databases | gzip > /volume1/Backup/mysql/database_`date '+%m-%d-%Y'`.sql.gz

This causes cron to run the mysqldump script at 2:15 every night.

Thirdly and finally, restart the cron service:

/usr/syno/etc/rc.d/S04crond.sh start

This came from http://forum.synology.com/wiki/index.php/Basic_commands_to_get_around_the_Synology_Box_using_the_CLI#cron

We think it is also wise to use the timebackup program to copy the backup directory to another Synology box, so that there are always two copies.

Cron seems to stop running from time to time, as the backups sometimes stop. This behavior may be due to Synology updating itself, and overwriting the /etc/crontab file. There is no way to prevent this from happening, so vigilance is needed.

To restore your mysql backup

The steps here are to gunzip the dump, and then load it into mysql. Mysql must also be able to run from the command line (see later section).

The shell file that I created to do this is rather simple: I put my dump file into the "public" drive, so change your shell file if it is somewhere else. Of course, edit the password.

gunzip < /volume1/public/database_YOURDATE.sql.gz > dump.sql
mysql -u root -pabcdefg < dump.sql

To get programs to run on the command line (i.e. mysql).

Again, this is a really bad idea. You should not be using your synology box as a linux server, unless you are just playing games with it. If you want to play games, you should buy a raspberry PI or arduino or something like that. Well anyway --

To do this you have to edit your synology path. If this is generally useful, then I suggest editing the /etc/profile file.

To edit this file, you must be logged in as root.

cd /etc; vi profile

Change the PATH line to add the last entry

Save it, log out, log back in, and then the PATH should contain mysql.

To mount files on your Synology NAS to Linux, working from windows

This is very difficult -- both ends - -Synology NAS syntax and Linux syntaxes for mounting volumes are both very cryptic. You will probably have to do some trial/error -- do not expect this to work "out of the box" so to speak. Pun intended there.

General information about Linux and setting up mount points:

nfs, or network file system, is the main linux file system. Synology, being a linux box itself, one would think should be very easy to mount to another linux box. Synology supports nfs mounts for some servers, but not others. In particular, the new 415+ encrypted server does not allow nfs mounts. This means you need to use some other type of file system. cifs is one. If you want to figure out what is going on -- it's not easy (which is why I wrote this). You can look at the "man" pages, but I found it useless. Linux documentation is very tough going -- it is generally written for system guru's, and contains far more info than you want to know, but without any working examples. The most useful sources are the synology site itself (unfortunately, it really doesn't work, but it gets close), and some user examples, such as this one:

The two (free) windows utility programs that you need for this are winscp and putty. Winscp gives you a windows like interface to your linux system. Putty gives you a command line interface to your linux system. You will need both. These are easy to download.

1. Prepare first by creating a mount point (/mnt/test is used in the examples below). This is most easily done by logging in as root from putty, and then mkdir /mnt/test.

2. For cifs, you may need to run (from the command line): sudo apt-get install cifs-utils (see here for more info). I am not sure if this is necessary, but it worked for me.

3. Create a /etc/cifspwd file as instructed on the Synology website as well as other places. This is a security measure -- by holding your login credentials in a protected file, you don't have to put them in broad view in your /etc/fstab

4. Next, you edit /etc/fstab (pick one of these two file systems) -- use nfs if you can get it to work.

  1. Linux (Debian) nfs solution: Mount the NAS directory to your server using fstab. This is somewhat erratic -- it will work for one Synology server, but fail on another for mysterious reasons.
    1. An example of line in fstab that works for some synology NAS servers: /var/www/xyz nfs rw,nosuid,noexec 0 0
    2. Some Synology servers will not work with the "volume1" part of the name (see below). This is a trial/error situation.
  2. Linux (Debian) cifs solution. Mount the NFA directory using cifs. (with 123 and xyz substituted for the real stuff).
    1. An example of line in fstab that works for the 415+ synology NAS servers: // /mnt/test cifs user,uid=root,gid=users,rw,suid,credentials=/etc/cifspwd 0 0
    2. Note that the name that Synology uses a for the SAME DIRECTORY is /volume1/xyz (not /xyz). This means that you have to translate between "synology-ese" and "linux-ese".
    3. Note that the style of the address for linux is DIFFERENT betwen nfs and cifs (sigh). This obviously means that you can't just mix/match mount lines in fstab for nfs and cifs.

5. Once fstab is modified, run mount-a. Hopefully this will just return nothing (meaning it worked). Other possibilities mean you have to go back and try every possible permutation over and over again until you luck onto the right one.

  1. It hangs. Type control-D at the console. sometimes it helps to run dmesg | tail (this gives you the last 10 lines or so of the error log).
  2. It says something is wrong.

To keep your domain users up to date

Synology does not have any method of updating your domain users other than you clicking on the update button -- yourself. You have to locate it in the control panel, and click on it. Domain services will shut down for a minute or so, and then come back updated. This is silly and unsafe (it should update itself every day). It is easy to see how an unwanted login could persist on the NAS, even though it was deleted from the domain server, as the "administrator" of the NAS has to go to each device, find this button and click on it.



© Copyright February 11, 2017 , Timothy C. Hain, M.D. All rights reserved.
Dr Hain's CV Clinic dizziness-and-hearing.com FLW Rant-Rave