The promise of the Synology DS918+ is that it’s a simple way to setup a powerful network attached storage (NAS) solution. This language is featured prominently in the description on Amazon:
High-speed scalable storage server
Featuring a powerful quad-core CPU, Synology DiskStation is perfect for home users or small businesses looking for a compact and reliable shared storage solution to process intensive workloads.
After a few weeks of near-daily struggle with the DS918+ and Synology’s shockingly poor support, I thought it time to share my experience.
Let’s Start With The Basics: Setting up the DS918+
This part was simple enough. I installed my three new 8TB Seagate IronWolf drives and ran through the basic setup, configuring them in a RAID 5 array. The DS918+ installed the available updates and I teamed the 1GB network cards for some added speed. I connected them directly to my router which is what my PC is connected to over gigabit ethernet and I set about transferring some data.
What I didn’t realize is that the software that powers the box, DiskStation Manager (DSM), would immediately put the array into a verification mode that went on for at least 24 hours and slowed everything else down.
My initial transfer of around 2.5TB of data went without a hitch. It took forever but completed without issue so I put that down to the sheer size of the data being transferred and the fact that the array was still being verified.
One Drive Down, Three to Go
I moved on to my next drive – an older Seagate external drive. It has a USB 3 port so I connected it directly to the NAS and it detected the drive without issue. I began the file transfer and it soon failed. The error given was just a generic one, and I couldn’t find any logs to debug with, so I reached out to Synology support on their live chat. Turns out, live chat support is basically useless for anything beyond the most basic troubleshooting. I’m talking really basic, like “have you checked to make sure it’s plugged in” basic. For anything else, you have to open a ticket.
Synology Support… Don’t Get Your Hopes Up
While I was struggling with failing file transfers, I was also trying to configure a custom domain name for my NAS. This is a confusing and poorly documented process which requires ports 80 and 443 to be opened on your firewall after you’ve configured both your NAS and nameservers at your domain name registrar properly in order to allow Let’s Encrypt to “see” your box so it can issue a cert. You also have to fill in fields just right, with the right combination of undocumented settings, or things will break without any useful errors.
I finally managed to get that done and then couldn’t remotely manage the box because when it’s using SSL it stops using port 5000 and begins using port 5001. Nothing warns you about this. You find that out the hard way when support finally reveals it after two days of back and forth.
File Transfers – Forget About It
After I finally got my custom domain name and SSL working properly, I opened a ticket for the file transfer issues I was experiencing. By this time I’d given up on transferring over USB and had moved on to attempting to transfer from a different drive within my PC, over the network to the NAS. This one failed, too, and also without useful errors.
Tech support asked a series of banal questions which ate up three days of back and forth via ticket replies. They eventually recommended that I connect my PC directly to the NAS and over ethernet attempt the transfer again. This would have meant I couldn’t use my PC for anything Internet-connected (so, anything) for at least a full day, because transfers between devices and the DS918+ are painfully slow.
If you’re trying to move a single large file it typically transfers at around 110GB/sec, which isn’t perfect but it’s pretty good. The problem is when lots of small files are involved. Then, transfer speeds nosedive. You could just let it run overnight or even over a weekend, but because transfers so often fail without useful debugging info, you can’t risk that.
How I Worked Around The DSM Transfer Errors
I ended using 7-Zip to create massive ZIP files (7-Zip, unlike the DS918+, will intelligently skip files it can’t copy), and then transfer the ZIP file to the DS918+ and extract it. (You may need to change your 7-Zip temp file location to the NAS in order to have enough room to create the ZIP.)
Once the ZIP transfer was complete, I ran into another issue; the raw power of the DS918+ simply isn’t what one would hope. I purposely bought a more expensive version from Synology’s lineup to have enough power to do more than archive data, and I know not to expect much from a quad-core Celeron processor, but it took 42 hours to extract a 2TB ZIP file. I’m pretty sure my phone could work faster than that. Synology’s response?
…unzipping files requires CPU power, given that CPU on the NAS is not as strong as your computer for example, it would take longer to extract.
Next up, Web Station, PHP, and WordPress
OK, so all of that was frustrating but at least I was able to work around it – even if Synology support was utterly useless.
Next, I decided to setup the DS918+ as a WordPress development server so I could easily spin up installs to work on without having to eat up storage on my primary servers.
This ended up being an even bigger nightmare than the SSL certificate and file transfers combined.
First, The Defaults
The DSM Web Station software defaults to using Nginx and PHP 5.6. That’s right – PHP 5.6; the one that was first released in August 2014 and is no longer maintained. You can install Apache 2.4 (originally released October 2017) and PHP 7.2 (also not the latest version, but at least it’s maintained), but Synology won’t support them and even denied that they would even work at all with WordPress.
However, I wanted to try it anyway. I manually configured a virtual host to use Apache 2.4 and PHP 7.2 and downloaded the latest version of WordPress and set everything up manually. This worked and allowed me to get WordPress running, but I couldn’t upload plugins or themes. At first I got an error and then it started prompting me for FTP credentials, which typically points to a permissions issue. After days and days of back and forth with Synology support over WordPress file permissions being bonkers, here’s what they said:
WordPress in DSM depends on PHP 5.6 and it might cause issues if you change the PHP version to 7.0/7.2.
Basically, they wouldn’t admit that the default permissions are a mess. Instead, they kept insisting that the issue was with PHP.
Now remember, I’m using their official PHP 7.2 package and Web Station allows you to select it and enable it for your virtual host, but somehow that’s not supported.
I even tried setting up WordPress using their app, which is version 4.9.8 (August 2018 – not even the latest version in the 4.9 branch). No dice. 404 error.
Oh, and the WordPress app on DSM requires Apache 2.2.34 – from July 2017.
Finally, I tried giving the “Everyone” account full read/write permissions, because they asked me to despite what a huge gaping security risk that is, and it resolved nothing.
The DS918+ is a purpose-built NAS that fails to deliver on the promises it makes. It’s not particularly easy to configure. It doesn’t boast fantastic performance, even for its class, and the support provided by Synology is the worst I’ve ever seen from a hardware manufacturer.
I do a lot of research before buying something like the DS918+. It’s got 4.5 stars on Amazon and five eggs on Newegg. Synology has been around a long time and is well known. They have extensive documentation (though, not for my purposes), and the product met all of my needs – on paper.
My mistake? Trusting those reviews, brand recognition, and documentation to be an indicator of a well built and properly supported product. I haven’t found anything that the DS918+ does particularly well yet, and at this point I’m just crossing my fingers that it will continue to function at all. Apparently, that’s a real issue.