-
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.
-
Secondly my cloud was waking up every two to three minutes, so I decided to upgrade the firmware too.
-
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.
-
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.
- 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
solution:
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.
Thus:
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
-
start up terminal
-
cd .ssh
-
mv known_hosts known_hosts.old
-
mapping a drive has a slight change to the server Address.
Before -
click anywhere on desktop to get to finder.
-
select from top bar menu Go then select Connect to Server
-
smb://MediaServer <== name of my Cloud
The slight change requires adding .local to the cloud name
thus:
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.
- start up your cloud dashboard
- stop cloud access
- 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.
- start up your cloud app on your device within the same wifi network as your cloud.
- remove all devices from your cloud app
- 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.
#!/bin/bash
/etc/init.d/wdphotodbmergerd stop
/etc/init.d/wdmcserverd stop
/etc/init.d/wdnotifierd stop
/etc/init.d/wddispatcherd stop
killall crond
drive_sleep.sh off
sleep 1
drive_sleep.sh on
hd_standby.sh 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
drive_sleep.sh on/off
hd_standby.sh 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 led_brloop.sh which contains:
#!/bin/sh
while [ 1 ] ; do
lbr
done
lbr will slowly fade your led to off and turn it back on, thus this loop will continue forever. The led_brloop.sh 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…
