Hi everyone!
It appears that my MyCloud EX2 Ultra is having trouble obtaining an IP address from the router via DHCP (all other devices on the network behave just fine). It always self assigns the IP address 169.254.235.75/16 while my other network is a regular 192.168.0.x/24.
At first I could at least access the browser frontend and there I saw that DHCP was selected in the options but the DHCP/network info on the top of the page was missing. After a few restarts, I now only get 403 errors when browsing to http://169.254.235.75.
I can connect to the machine via ssh just fine, and there I added a proper address (>> ip addr add 192.168.0.10 dev egiga0) which allows me to talk to the device on that address again. Still, browsing to http://192.168.0.10 only returns a 403.
I’d like the device to use DHCP again, so that I can configure its IP address via the router. I also tried the soft reset (hold reset button for 4 seconds) with no effect. It is still getting the same old IP address every time.
Since I can not access the frontend I can not get the current firmware version or update it. I did not actively update to OS5, so I assume it is still on OS3. Since the behaviour changed during reboots, I assume that ‘some’ firmware update was automatically installed. If anyone knows how to check the firmware version over ssh, then that would be great as well.
thanks, Simon
PS: I assume that the Issue with the broken IP setup started some months ago. I could not access the drives from Windows anymore but still from OSX. Windows uses an IP address, OSX uses zero conf so I guess the IP change happened back then. I did not have the time to investigate the issue back then.
So - - - bear in mind that OS/5 only plays nice with the public IP ranges (192.168.xx.xx;172.16/32x.x.x;10.x.x.x)
But if you are on OS/3. . .then that isn’t the problem.
So it sounds like a DHCP problem; where a static address is assigned either from the router or the NAS. . outside of the ip range of the rest of the network.
Possible steps (Short of 40 second reset)
- Verify that you are not assigning the IP address from the router.
- Temporarily change the working IP range of the router to include the 169.254.235.75 range. . .then log into the NAS dashboard. . .and see if the IP range is being fixed by the NAS. (it should be Dynamic). Once you have the NAS set to dynamic. . . .you can reset the router IP working range where you want it. . . .and assign a “better” IP address from the router.
FYI: If I was you; I would block internet access to the NAS from the router. With the known security vulnerabilities of OS/3 - – you really don’t want that device exposed to the internet (turning off “cloud services” is inadequate). OS/5 is supposedly better; since it is based on 4 year old Linux (as opposed to much older Linux). . .but it has certain privacy concerns associated with it.
thanks for the quick reply!
I added the 192.168.0.10 IP address via ssh (see above for details) so I can now ‘access’ the device via the browser on both IPs (http://192.168.0.10 and http://169.254.235.75). I put ‘access’ in quotes, since the device only returns a 403 forbidden error (all browsers, private sessions and whatnot). The computer from which I try to access the frontend also has a 192.168.0.x/24 address.
Adding the the well known public address was my attempt to work around the issue with OS5 being picky out IP ranges… Maybe just adding the address is not enough?
I had a fixed IP assigned from the router (192.168.0.10, outside of my DHCP range x.x.x.100-199) which did not work, and the I removed the the assignment (plus reboots of the NAS and router) with no effect.
Are there any logs where I could see why I am getting a 403? Maybe that can shed some light on what’s going on there…
I already put the NAS on the blacklist when the OS3 vuln lit up the internet, but I’m not 100% sure it worked. when the frontend was still working (even though on the odd IP address) It reported the internet connection as active… backing up important bits of the backup right now…
I looked up the assigned IP address… It’s from a block that is not assigned yet, so might that might be a sign that the device was compromised after all, but luckily not wiped…? Can anyone remember the details of the OS3 vuln?
I have an Asus router with stock firmware.
I recently had issues with getting “network services filter” to work properly; but was capable of blocking ALL WAN and VPN access via the “block” on the Client Status page (the VPN block was an unattended side affect).
I bring this up because there maybe some funky unintended filtering going on when jumping subnets or when you have multiple IP assignments involved. This sounds like funky filtering.
I still recommend adjusting the router temporarily to putting the entire network on the public range. . . and then seeing if you access the NAS. . . .and if then checking if you are assigning an IP address from the NAS.
Do you have OS/5? If so. . I think you are stuck with running the network on a public IP range. I have had the same problem with Roku sticks.
For “Testing”; I use a laptop hotspotted to cell phone 
Then see if I can SSH into the box.
I am digging deeper into apache to see where the 403 comes from. Turns out theres a few require directives with the bogus IP in the httpd.conf.
/usr/local/apache2/conf/httpd.conf: […] Require ip 169.254.235.75/16
My apache config knowledge is a bit rusty, but I guess that means that it only allows access from that /16 block of the bogus IP. I am getting more and more the feeling that the device was compromised…
edit 1: for what it’s worth, here’s some other places where the bogus IP showed up:
/etc/NAS_CFG/config.xml
/etc/upnp/nasdevicedesc.xml
/usr/local/config/config.xml
I’m just doing a >> grep -r ‘169.254.235.75’ /
edit 2:
the config file (both /usr/local/config/config.xml and /etc/NAS_CFG/config.xml read ‘2.41.116.1117.2020’ as the version.
edit 3:
after editing all the ip addresses in the files and doing a reboot, the bogus address seems to be restored… anybody know how I can restart apache, after fixing the httpd.conf?
edit 4:
more bread crumbs if anyone stumbles over it. I fixed the httpd.conf and restarted apache with
/usr/sbin/ apache restart web
and the 403 issue is solved.
