aol

- Outcome of the installation/update: SUCCESSFUL - DSM version prior update: DSM 6.2.1-23824 - Update 3 - Loader version and model: JUN'S LOADER v1.04b - DS918+ - Using custom extra.lzma: NO - Installation type: BAREMETAL - GA170X-UD3 build-a-box w i7-6700K cpu and 4@WD RED 2/3 TB HDD

Caught my eye. I have had terrible experience lately with WD Red drives crashing. Phase 1 of my xpenology career: had 4 WD Red 1/2 TB drives in an old Intel SS4200E NAS enclosure, and never had an issue for probably 4 years. Not a single drive crash. Phase 2 of my xpenology career: had 4 WD Red 2/3 TB drives in a GA Z77X-based system, and dropped a drive a month. About every month DSM would complain that a drive had crashed. Third party tests on the drives never seemed to indicate anything was really wrong with the drives but from DSMs perspective they were just bad. I must have RMAed about 8 WD drives over a 6-8 month period. When I built this system I set it up as BTRFS RAID 5 but after a little while I rebuilt it RAID 5 (non btrfs). I re-evaluated the PSU, the SATA connections to the motherboard, the BIOS version and settings, etc., etc. Drives would routinely crash with just a few hundred hours on them. I think I experimented with several generations of bootloader e.g. jun 101b/102 which means different gens of Synology-spoofed hardware (3615, 3617, 916 if I'm recalling those models right). System lasted about 8 months. Phase 3 of my xpenology career: 4 WD Red 2/3 TB drives in a GA Z170X-based system. So far this system has been up about 2 months maybe 3 and it did lose a drive, but it was a legitimately old drive which could have legitimately crashed (out of warranty). It was 103b/3615 for awhile, now it's 104b/918+ (RAID 5, non-btrfs). I agonized about the 3615->918 upgrade but actually the system went unbootable and the cleanest path forward seemed to be to go to 104b/918+ bootloader. All I do on these systems is Plex really. I have a real Syno NAS that I use for everything else but which just doesn't support Plex transcoding well. I don't really have any help, just, seeing your experience with a crashed drive made me recall my nightmare of drive crashing. Still don't know what was going on or if the problem is going to return in my current build.

Definitely you want the disks set in AHCI mode. Don't use onboard raid, DSM does that for you. I think you want to use UEFI drivers in the BIOS, not legacy? Don't know about the DVD drive.

I've had many drives go bad on xpenology boxes. In every case my experience was the same, shut down, replace the drive, boot back up, go to the disk management UI, and repair the affected array. The UI will ask which free drive to apply to the task, select your new drive, and it'll do it's thing. Your data is available in the meantime but the system will spend approx 12 hours rebuilding. This will cause it to miss it's next scheduled shutdown if it conflicts with the rebuild, FYI. I've never had an SHR, I've always used RAID 5, but I would expect your experience to be the same.

- Outcome of the update: SUCESSFUL - DSM version prior update: DSM 6.2-23739 - Loader version and model: JUN'S LOADER v1.03a2 - DS918+ - Using custom extra.lzma: NO - Installation type: BAREMETAL - GA-Z170X-UD3 - Additional comments: Had just gone from a DS3615 on Jun's v1.02b loader running DSM 6.1.x to DS918+ on Jun's 1.03a2 loader, chose to install clean rather than migrate, all ok

So where are we? It appears that you: - identified that your network infrastructure was not the issue because WOL worked on other boxes, and works on the NAS if you do a forced shutdown (remove power vs. menu -> shut down) - made sure that eth0_wol_options="g" in root/etc/synoinfo.conf - made sure that support_wol="yes" in same file - made sure WOL was ticked in DSM GUI - added an rc.d startup/shutdown script named root/usr/local/etc/rc.d/S99ZZZ_Shutdown.sh with the contents from that post (this script appears to do two things: on startup, if the /var/packages/shutdown_script/DSShutdown.sh file exists, it runs it, hopefully you don't have this file; on shutdown it executes the command `ifconfig eth0 down`, which is the command to turn off your eth0 network adapter, which is typically your first or only ethernet port) - made it executable via `sudo chmod 755 root/usr/local/etc/rc.d/S99ZZZ_Shutdown.sh` which makes it executable by owner, assuming you created it as root, it would be owned by root My understanding is that the linux OS DSM is built on is designed to automatically execute scripts in the root/usr/local/etc/rc.d directory on startup passing 'start', and on shutdown passing 'stop', in alphanumeric order, hence that name, which should cause it to be executed last of the rc.d scripts. And now you are at a weird place where the box doesn't come up clean some times and if it comes up your packages aren't running or aren't appearing correctly in the GUI? Do you have a file called /var/packages/shutdown_script/DSShutdown.sh? If you do, it appears to be being called at startup if I understand the script. I don't know that you really want to do that. Searching for that file name, I found https://sourceforge.net/p/advpowermgr4ds/discussion/bugs/thread/095d53ea/#8356 indicating to me that it's possible someone reused the script from this post, didn't understand what it did, but since they didn't have /var/packages/shutdown_script/DSShutdown.sh it didn't have any adverse effect. That post has references to the files mentioned in the script which confuse me about why they are being referenced at all. The whole post seems to be about hijacking a Syno package called shutdown_script which may be a pre-requisite for that other post. The right script as far as I can tell (UNTESTED BY ME) would be #! /bin/sh case $1 in start) # No-op ;; stop) ifconfig eth0 down exit 0 ;; *) echo "Usage: $0 [start|stop]" ;; esac This script assumes that /bin/sh is the right path to the shell interpreter, which it probably is. It doesn't exit with any code during startup, which is probably fine but may result in a log message. It exits successful (0) during shutdown after doing what you want, which is to turn off your eth0. The `*)` means, if run with any other than start or stop, do this, hence usage. So back to your problem, if you have a /var/packages/shutdown_script/DSShutdown.sh file it could be causing problems, and I don't understand the changing of eth0_wol_options="d" to "g" to know if that could cause problems. EDIT: as far as I can tell, the eth0_wol_options="g" in root/etc/synoinfo.conf attempts to tell the ethernet card to set Wake-On to "g" (rather than "d"). "d" is disabled, "g" is wake on magic packet. Its the same as doing it manually via the ethtool command, e.g., `ethtool -s eth0 wol g`. You could issue the command `ethtool eth0` to see the settings for the ethernet card. If everything is set properly you should see included in the output Supports Wake-on: pumbg Wake-on: g the Supports line should include g (the other values don't matter, it needs to support wake on magic packet which means it needs to include a g). And the actual Wake-on setting needs to stay g.

Couple notes as I've gone through the ringer a few times on WOL. First, your root password is just your administrative user's password. If you have ssh enabled (default port 22), then you should be able to use Putty to ssh in with the same credentials as you use to log in administratively to the UI. There used to be a secret password to ssh in with that varied by month and so on, I don't know if that's still true, it was used by Synology support to get into your machine in emergencies. But if you can log in to the UI as administrator, that should work for ssh. IIRC you would `ssh <admin user id>:<admin password>@<nas IP>` or the equivalent Putty. I believe you can then `su root` with the same password, or just use sudo. Second, in order for magic packet to work for WOL, you need to not only have your hardware set up to acknowledge the magic packet, the box has to actually GET the magic packet. Any network devices between the system you're sending the packet from and the NAS _could_ be blocking the packet, which I believe is typically a UDP packet sent on port 7 or 9 (double check, it may even be 22). It's unlikely your sending system is blocking it, firewall rules don't usually prevent outbound packets. But your router could be blocking it. I had a FIOS router and I had to perform a manual step to add a static route to the ARP cache (that Putty command you're trying to think of) of the router so that the router didn't forget about the NAS when the NAS was turned off. So, consider that the packet may not be making it through any intermediary network device. Good luck. EDIT: Good blog post on this, although his situation involves both an ISP modem/router and an internal router and he can't put his internal router in bridge mode so he has to create a DMZ, which is hopefully more complicated than your setup. http://www.dreamcraftdigital.com/setup-wake-on-wan-with-the-asus-rt-ac68u-router-and-the-synology-ds216j-nas/

Thank you @jun and @Polanskiman, and all the folks that keep the site up and the loaders coming.

Alright I resolved the issue with a BIOS firmware update to the motherboard. A huge pain because I don't have Windows, so I had to use a USB pen drive to install Win10 to a spare drive, then use the @BIOS utility. Anyway. Thanks so much @flyride, @Tensol and @sbv3000. Your suggestions and patience were very helpful. Cheers.

I am waiting a long time, several minutes, for SATA detection. I did try the idea of connecting the DS410 drive (one of them) to ANOTHER system and it is detected no problem. The other system is a GA 10-series board, so, newer. At this time I'm assuming there is a firmware issue on the ex58 board that's simply preventing it from seeing the drive, due to some modification to the MBR or something that Synology DSM does to drives it manages. I'm in the process of updating the ex58 firmware, on the off chance that the slightly newer beta bios that's out there may have fixed this issue (fixed may not be the right word, this is a pretty edge-case, um, case). That turns out to be a huge beat down because the native utilities recognize 1MB BIOSes but the beta BIOS is a 2MB BIOS, requiring Windows to run a Windows BIOS flasher, but I don't have Windows. I may have to actually install Windows 10 to a spare drive to upgrade the BIOS. Alternatively, re-initialize the drives. You asked DSM version, it was the latest supported on the system, 5.2 I think. By "unreadable" I mean, when you attach a drive in a GUI-unsupported format to Mac OS it puts up a dialog saying "this disk is unreadable, intialize ignore or eject". So as you say, they're formatted Linux partitions which Mac OS's GUI-native drive mounter doesn't recognize (you can issue terminal commands to mount it). I'm intrigued by the idea of setting up the Xpen on another drive and hot-mounting the DS410 drives. As this is a build-a-box what does that look like: get the GUI running on another drive with the DS410 drives installed but the SATA cables disconnected? Then plug in each SATA cable? Or have each drive connected to SATA bus but not have power, and plug in power? When I hot connect to my DS1515+ I just insert the drive which connects SATA and power at the same time. Not sure it would survive a reboot since SATA detection would presumably fail again, unless, possibly the upgrade to DSM 6 re-modifies the drives such that they BIOS SATA detection firmware routine can now see them (or I hot plug each time, ug). At any rate thanks again for all the responses. Great community and I'm glad to be a part of it.

Thanks sbv3k. I tried to post a question to Synology but their web form seems to have a javascript bug. I have no idea if my question got in or not, or if they'll respond, for the reason you mentioned. I considered jumpers, I'll double check that. I like the idea of setting the "good" (other) drive on sata channel 1 and seeing what happens if the DS410 drives are connected on 2+. I'll try that. It's possible the motherboard or controller is bad, for sure, hardware breaks eventually. I don't have another controller to try but that's a possibility. I do have another build-a-box I could try a drive in. I'll try IDE mode just to see if that does anything different. Thanks for your suggestions. Not really worried about data loss - all the data has been backed up to a 1515+. At this point it's more stubborn curiosity about why this is happening than anything else. You live by certain rules and this situation is breaking my rules. Ha. "known good drives do not hang SATA detection on known good hardware". So something is wrong in that "rule".

Thanks for posting Tensol. I did hand-edit the BIOS (with no drives attached since it won't take me into BIOS settings edit with any DS410 drive connected) to set boot order to USB/disabled/disabled. With any DS410 drive attached it shows the splash screen (showing 'hit DEL to enter BIOS'), goes to SATA detection, hangs. In it's previous incarnation the Xpen box had 4 WD Red 3TB drives, and a USB stick running Jun's latest loader, and DSM was up-to-date. In it's current incarnation it has the 4 WD Red 2TB drives from the DS410, same USB stick, but of course DSM is old since the DS410 doesn't support DMS 6. I certainly considered if there would be something funky with the USB stick, but it had 4 drives and still has 4 drives, on the same SATA ports. And, it's not even getting to the boot part of the startup, right. It stops at the SATA detection scan way before even trying to pick something to boot from. I've considered putting the drives back in the DS410. I have no reason to think they wouldn't work. The 410 was a rock for 5 years +. I did put each drive in a USB drive caddy connected to a laptop, and each drive spins up and reports "unreadable" since they are ?linux?DSM proprietary? formatted. I put them back in the Xpen box and they seem (by touch) to be spinning up. Firmware incompatibility? These drives are probably 5-6 years old. Could the BIOS on the mobo simply be unable to read the firmware on the drives? Could the drives be stuck in some sort of low power mode? Technically I could ask Synology this. All I'm doing is taking drives that were in a DS410, and moving them to a build-a-box PC. I may submit a ticket to them on it.

Hi flyride, thanks for posting. The issue isn't boot order, it isn't trying to boot to the sata drives, it's doing it's AHCI SATA detection scan, pre-BIOS. For example, if I remove the drives, and hit DEL to enter BIOS, it does the SATA detection scan (of course finding no drives) and takes me into the BIOS to edit settings. If I connect a single DS410 drive, it hangs on SATA detection, and never takes me into the BIOS. (connect any other drive and DEL takes me into BIOS edit as normal) It shows the splash screen, goes to SATA detection, and hangs there. Unless I'm missing something, changing boot order won't help get past SATA detection. Note that in trying to solve the issue I disconnected all drives, went into BIOS, loaded optimized defaults, set the boot order to USB first (and all others disabled), and rebooted. But again, with even a single drive connected, I can't get into the BIOS again to see (since some BIOSes alter boot order when new drives are introduced). For sure if I can get past this issue I'll set the boot order to be USB/disabled/disabled.

I put the 4 disks of a Synology DS410 into an Xpenology box running the latest loader via USB stick. This Xpenology box had previously been running the latest Synology DSM using different disks that I migrated to a DS1515+. I expected the Xpenology box to boot up and either report the 4 disks from the DS410 migratable, or not, and deal with it. But it did a third thing I did not anticipate. As the Xpenology machine goes through loading the BIOS and doing the SATA disk scan, it just pauses during the SATA disk detection scan. It does not reach the Xpenology loader on the USB stick. I tried: - disconnecting all drives: boots to Xpenology boot loader - reconnecting each drive one at a time: SATA scan hangs - connecting an unrelated spare drive: boots to Xpenology boot loader So I've ruled out stuff like misconnected cables. It's almost like the drives which used to be in the DS410 are confusing the SATA detection routine. For what it's worth this is a Gigabyte 5 series mobo, a GA-EX58-UD3R with a core i7-930 CPU. Again, this same hardware has for months been running Xpenology/DSM with different disks. Anyone have any thoughts on why WD 2TB Red drives that used to be in a working DS410 would fail to be detected cleanly by the BIOS of a GA-EX58-UD3R board? I guess my next step is to use USB drive mounting hardware to mount and reformat each drive from my laptop. I just hate to do that, wouldn't mind migrating the data.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.4 15217 UPDATE 5 - Loader version and model: JUN'S LOADER v1.02b - DS3615xs - Installation type: baremetal GA-EX58-UD3R - Additional comments: Applied using auto-updater set to run prior to scheduled shutdown, box came up clean

Great news. Curious what you think was the thing that got you going? As far as the next step, I would think if SynoOS says the array is recoverable then you'll be fine, but I would understand you wanting to get a second opinion. Keep in mind the SynoOS files, and the data in the RAID array, are separate. You can migrate the SynoOS (e.g. from a DS3615xs to a 3617xs model) and the data won't change, just the SynoOS will need to know what sort of RAID array it's working with (this is migrating, the same thing as if you physically moved the drives in one NAS box to another NAS box). I would think recoverable is between healthy and migratable, that is, less work will need to be done to get your data back, but I could certainly be wrong. Anyway my vote is to trust SynoOS, if it says your data is recoverable and it will let you click a button to recover it, then that's probably the right thing to do.

Sounds like you have video output from the box and if I understand you you get the normal BIOS output but you do not see the normal output from booting the stick, e.g., you should see the menu, and after a few seconds, the screen should post a few lines of text indicating it's begun booting and then nothing more will appear there. If you are not getting that output then find.synology.com won't work. Rebuilding the stick may have caused a problem if you were not careful to rebuild the grub.cfg with the correct vid, pid, SN and possibly mac. Building the stick on a mac is simpler than on a Windows machine, simply sudo dd if=/path/to/102b.img of=/dev/disk3 bs=1m in terminal. determine the correct /dev/disk3 path using diskutil list. Your USB stick will be /dev/diskN. Then you need to mount the EFI folder of the stick, edit grub.cfg, set the vid/pid/SN/mac, unmount and done. So that should be your focus, getting the system to display the right text on boot.

does sudo su work on Synology boxes?

Should be fine. I assume you've verified that 6 disks fit inside the case, and you want to make sure things stay cool so maybe add an internal fan or two if you can. You are mixing and matching drive sizes and that won't cause a problem but optimally they'll all be the same size (3TB or 4TB) AFAIK (maybe there is a use case I didn't consider for doing this). You might also put 2x4GB RAM in there assuming the mobo has dual channel memory support which will make things run a smidge better AFAIK. There's some debate about 4GB RAM or 8GB RAM, I probably lean towards 8GB. Maybe someone has a good reason for only 4GB I'd be interested in hearing. I don't know much about that CPU, I've generally used core ix CPUs which have built in GPUs. Plex added hardware video encoding/decoding, which uses the built-in GPU of the core CPUs. Now my understanding is it's not awesome and may not be worth upgrading your CPU purchase to take advantage of (if that CPU doesn't have an iGPU). But something to consider. Set the drives in AHCI mode in the BIOS, FYI, when you put it all together. I made the mistake of not doing that and had to rebuild the OS a few times.

I'm having trouble getting my Synology to connect to a VPN as a client. The client connection works from other devices so it's not an authentication thing. Bottom line I'm wondering about using ruTorrent or the deluge docker, and protecting yourself by downloading over a VPN. @viper359 are you using a VPN with ruTorrent? @bglf83 does the deluge docker run a VPN client you can configure? And how do you deal with "only download while the VPN is up; if the VPN isn't up, don't download anything until it's up"?

It's not really an issue of why shouldn't the PC see the NAS but more why SHOULD it. There are a bunch of things that have to be set up right for the PC to see the NAS. - they must both have a file sharing protocol enabled (the PC is the client, the NAS is the server). this is typically SMB or CIFS. it's hard to believe it's disabled on the PC, but it is not on by default on the NAS. double check that file sharing protocols are enabled and all sub requirements such as workgroups match up. - they must be able to physically see each other on the network. you must be able to ping back and forth. typically they're on the same subnet, e.g., 192.168.1.* with the same net mask (255.255.255.0). keep in mind ping commands can get bounced by the nas. you could temporarily enable ssh, but you need to determine that the boxes can see each other. - there must be no intervening device such as a firewall blocking the two from seeing each other. windows PCs, Synology NAS and many routers have built-in firewalls which may prevent traffic. while you're getting this worked out try disabling the firewall on the PC, the NAS, and any intervening network device. - authentication: SMB still requires authentication, a user and password, that has been set up on the NAS (unless you're using LDAP on the NAS for your users but that seems unlikely given the problem you're having) bottom line you need to prove to yourself that it should work and not assume it will. If you determine your NASes IP, and go to Windows Explorer, and put in //<ip of NAS>, what happens?

A discrete video card can be used by Plex for transcoding but there are significant limitations and at this point I would say don't do this. Otherwise, as sbv3000 said, NASes run headless so a video card is only useful to edit BIOS settings and to perhaps make sure that initial boot succeeds so that find.synology.com works. Late gen intel CPUs have a built in GPU which should be sufficient (unless you want to optimize for Plex hardware transcoding). RAM is cheap, no reason to not follow sbv3000's advice there. You could go less but you want to take advantage of your CPU/mobo's architecture there. Tri-channel you'd probably do 3x2GB. CPU-wise an i5 is probably sufficient, keep in mind Synology NASes use generally weak CPUs. You can go to Synology's "what cpu does my NAS have" page and see what they use, and get something better, to try to future-proof yourself. You might check out your library or school which routinely liquidates hardware, eBay or craigslist. Plenty of folks on this forum use server-class hardware, and buying used a few generations old would probably meet your needs.

XPE+DSM doesn't require RAID hardware. My motherboard has RAID hardware but DSM creates it's own software RAID array I believe. I set my disks in AHCI mode and DSM does the rest. Far as I know you can use any DSM RAID configuration including SHR, although I recall something about the different models (3615xs, 3617xs, 916) having one small issue regarding a RAID config that one or two support but not all three, but I forget the details on that. If you run Windows in a VM or Docker on top of XPE+DSM, you will probably lose FPS in games. I think folks that VM do it the other way, Windows native and XPE+DSM in a VM. Yes, the Windows box and the VM would have to be running for the XPE+DSM to be running. I personally run XPE+DSM on dedicated hardware. I don't have any experience with the other vendors. I started with a real DS410, then found this project and have used it on two different bare metal installs. Main thing is to think about your use case and figure out the tradeoffs.

Any DSM will be ok with SynoCommunity packages... but the DS version you are running (3615xs, 3617xs, 916) has a hardcoded architecture regardless of the actual CPU you have inside your xpenology. An xpenology that has been told by nature of the bootloader that it's a 3615xs can only _install_ (through the Package Center GUI) SynoCommunity packages compiled for bromolow architectures or SynoCommunity packages that were compiled with "noarch" (no architecture specified). In reality of course any 64-bit CPU can run almost any 64-bit compiled program; it's a matter of the instruction sets that the compiled package uses, stuff like SSE, SSE2, SSE3 etc, MMX, etc. You're obviously not going to change your CPU, the only way it'd be an issue is if you specify a model and architecture that results in installing a SynoCommunity package which expects (let's say) SSE5 instruction set support but your CPU doesn't actually have that support. Then that program will crash most likely. So that's a point in favor of choosing a model that is closest to your actual CPU and if in doubt behind (since later CPUs generally support the earlier instruction sets). Broadwell adds support for later instruction sets but as we discovered many SynoCommunity packages haven't been compiled (yet) for Broadwell so it doesn't do you any good. Really depends on your need. Plex (my main app) runs regardless of model. Most of the popular apps in SynoCommunity run on Broadwell by nature of compiled for "noarch". But some don't.

Just found one important difference between ds3615xs and ds3617xs, the former is "bromolow" architecture, while the latter is "broadwell" architecture, which means that since SynoCommunity packages must be recompiled for architecture and many have not yet been recompiled for the broadwell architecture, many SynoCommunity packages are unavailable on DS3617xs. Now hopefully it is just a matter of time but meanwhile, this limits SynoCommunity package access on 3617xs.