Mac Sierra and what it means to your Cloud

  1. Yesterday night I decided to upgrade my OSX El Capitan to Mac Sierra since I’ve been having troubles getting my HomeKit remote access working with the Apple TV.

  2. Secondly my cloud was waking up every two to three minutes, so I decided to upgrade the firmware too.

  3. Lastly after all this was done, I decided to move my wall plugs for my router from outside of my desk to the power bar behind my desk, thus rebooting my router and switch also.

  4. add some internet outages this morning

With all four events, it apparently caused quite a bit of havoc with my setup. Since my changeover from the 4TB clouds to the new 8TB clouds, I have left most of my devices to DHCP, so with the reboot of the router and the powering up of my Mac mini, Apple TV and my MacBook, suddenly my Cloud was no longer at the same iP that it originally had and thus Remote Access was interrupted. When my Cloud rebooted, it had the same ip as my MacBook.

Thus I spent literally hours trying to troubleshoot whose fault it was, or rather a solution to all the problems that kept cropping up.

So lets start with Sierra.

  1. we cannot issue a simple SSH from Mac terminal to the Cloud now. It returns a no matching host key type found. Their offer: ssh-dss


so this is how I use to connect:
ssh root@mediaserver.local <=== name of my cloud, you can also use the ip of cloud here.

now you must add -oHostKeyAlgorithms=+ssh-dss to your login telling sierra that you wish to use a legacy key exchange algorithm.
ssh -oHostKeyAlgorithms=+ssh-dss root@mediaserver.local

and it should prompt you for your password as normal.
In addition, if you have changing ips, like mine, you may need to

  1. start up terminal

  2. cd .ssh

  3. mv known_hosts known_hosts.old

  4. mapping a drive has a slight change to the server Address.

  5. click anywhere on desktop to get to finder.

  6. select from top bar menu Go then select Connect to Server

  7. smb://MediaServer <== name of my Cloud

The slight change requires adding .local to the cloud name
3. smb://MediaServer.local

Although you can browse and connect in that manner, the problem is that the default connection is AFP, rather than SMB of which I don’t know if Mac Sierra has improved the speed of AFP or whether the speed problem may be with the Cloud. Anyways if you connect using the browse method, it ends up using afp://MediaServer._afpovertcp._tcp.local

One of the known problems within my house is that AFP will send wake up signals, when mapped; since my Mac Mini is used as my entertainment system, it has the cloud mapped which can be one of the reasons that my Cloud keeps waking up. Also AFP has been known to be slower in file transfer (40-60MB/s AFP versus 60-80MB/s SMB) but faster in reading the directory names (30 seconds versus 30 minutes with SMB on very large directories like 10,000 entries ).

Restarting Cloud Access

There are a lot of reasons why you might be unable to get access to your cloud despite your cloud working normally within the confines of your home. Of course the number one reason of which you suspect that your cloud is not working is because WD services is down again. Yup it was down last week and the week before and certainly the year before that, but it worked yesterday just before that firmware update, so it has to be the firmware again.

The one known fix for all the problems with remote access is simply do the following.

  1. start up your cloud dashboard
  2. stop cloud access
  3. start cloud access and watch the information that pops up. It should say connected within a minute or so.

This toggling of the cloud access, upon turning it back on, sets up your port forwarding on your router and connects to WD to confirm your WAN ip.

Now do this on your Cloud App on your mobile devices.

  1. start up your cloud app on your device within the same wifi network as your cloud.
  2. remove all devices from your cloud app
  3. add your cloud device

Once this is done, turn off wifi on your mobile device and use your LTE to connect to your cloud. Repeat the above two sets of steps if you still have problems.

The Cloud Nefarious Wake ups

This is a fight that we will never win but we can certainly try.
This is the script that I use now on a gen2 cloud and it seems to help. For Gen1 users, search for my old sleep threads as those are still useful for an almost permanent sleep.

/etc/init.d/wdphotodbmergerd stop
/etc/init.d/wdmcserverd stop
/etc/init.d/wdnotifierd stop
/etc/init.d/wddispatcherd stop
killall crond off
sleep 1 on 5

Remember to do this after your set cloud access ON otherwise turning on cloud access will restart all these services. Let the scans run for a while, otherwise I think your drive will constantly wake up due to some background check on whether or not you have added data to your drive.

Yup I found a bunch of ready built scripts in /usr/local/modules/script
two of them seems interesting on/off now/2-10

I think my cloud is either confused or is trying to fool me by pretending to sleep. It is blinking the slow led blink while the drive is awake (I can hear it spinning and clicking).

The slow blinking lights are no longer hardware controlled but rather by a script called which contains:


while [ 1 ] ; do

lbr will slowly fade your led to off and turn it back on, thus this loop will continue forever. The is started and killed by set_pwn which is a compiled program (or a compiled script) which has the following parameters:
set_pwn 0-10 <== where 0 basically turns the sleep to off

however if you killall set_pwn
you should restart it with
set_pwn& <==== runs in background, otherwise when you exit SSH, set_pwn will terminate.

So that is it for today…

Those commands you issued to deal with the wake ups. Which firmware version are you using? Are they for one particular firmware version or will they work on both the old and new single bay My Cloud firmwares?

my bad… gen2 only I believe… unless they copied the scripts to a gen1. Try issuing those script commands on a gen 1…

I’ll make that clear on the first post…

Thanks Bennor…

Since lbr and set_pwn are executables they won’t run on the gen1 because of the 64k page size.


PS This thread shows a good reason to use DHCP reservation if your router supports it.

I had absolutely no problem logging into Motion aboytyCloud ssh just as I always have. It did ask the standard question about no previous key but once I permitted it, there’s no problem.

gen1 or gen2 cloud? perhaps it is only a gen2 problem then…