Upgraded to Cloud OS 5: no web access, no iSCSI access, just a nightmare!

My Cloud OS 5 Personal & Network Attached Storage My Cloud EX Series
1

EDIT: Reporting on an EX4100 device with 4 HDDs.

This is a living nightmare. I upgraded to Cloud OS 5, only to find out that the interface ip I used to connect (the interfaces are on different lan segments) got lost. I connected via SSH to the second interface and gave manually the ip address/mask/broadcast address to the first one. I was able to connect and was greeted by the wizard.

Followed the instructions, all seemed well. Even visited the config pages to re-enter the ip details of the first interface to make sure things are right.

Shared initially seemed ok, but my single iSCSI volume was not available at all. Instead a progress indicator was stuck at 3%.

I decided to reboot the device. And at that point came the final drop: I again was not able to connect to the usual interface. And also to the 2nd one! I did manage to SSH to the box, but doing a netstat shows that there is no listener at either port 80 or 443, only on IPv6 (which does not work in my IPv4 environment).

What kind of QA produced this released firmware ffs? How can I manually try to start Apache on the interfaces?

2

For the love of God, SOMEONE???

Second day without access to my 1Tb iSCSI work data volume!!!

3

Had some progress finally regarding the issue: it seems that the inability to access web admin stems from the fact that HTTPS access seems broken!

I’ve confirmed that by upgrading to Cloud OS 5 another box, which was configured to allow plain http logins. Before the upgrade I could simply elect to substitute https for http in the login URL and connected over https.

After the upgrade of the box, plain http access worked just fine. Trying to connect over https though is impossible.

On the box I had the original issue, after the upgrade if i try to login to the http page some sort of redirection to https takes place, rendering page access impossible!

How can I configure the problematic box to provide access over plain http, using shell access (over SSH)?

5

THANK YOU for taking the time to help someone desperate here! Can’t really stress just how much I appreciate any and every word of wisdom provided!

I did those commands. Result follows:

root@wdnas apache2 # sed -ie 's/httpsPort = 8543/httpsPort = 443/g' /etc/nasAdmin.toml
root@wdnas apache2 # /usr/sbin/nasAdmin.sh restart
Stopping nasAdmin
Starting nasAdmin
2021/02/03 15:20:14 nasAdmin starting, config file (use default config if none specified):/etc/nasAdmin.toml
2021/02/03 15:20:14 nasAdmin starting, log file: /var/log/nasAdmin.log
nasAdmin started
root@wdnas apache2 # killall httpd
root@wdnas apache2 # httpd -f /usr/local/apache2/conf/httpd.conf -k graceful
[Wed Feb 03 15:20:46.585519 2021] [core:warn] [pid 28136:tid 3068480832] AH00111: Config variable ${WD_TZ} is not defined
[Wed Feb 03 15:20:46.585630 2021] [core:warn] [pid 28136:tid 3068480832] AH00111: Config variable ${MYCL_ID} is not defined
httpd not running, trying to start

Unfortunately it did not work and after a reboot the changed values reverted back to the original ones (as you’ve stated in your post).

Any idea of where to look to disable forced https access? I am able to connect over plain http to my second upgraded 4100 (even though https is impossible on that too).

6

Forgot to mention that the criticality here is that the volume was created as an encrypted one, with password provided on each boot via web admin! Therefore, all my backups are unavailable!

7

@carmik I need to have screenshot and system logs please. You may PM me for the logs.

8

That’s impossible since I can not log to the web interface at all! I can gather logs after connecting over SSH, if needed. I also have opened incident # [210203-004535].

10

I did not fail to test that, I did fail to report that back, apologies. Https does not work, regardless of port choice (443/8543)…

12

@htb I’ve had a breakthrough. Some extra details first: the problematic box as I’ve said has two different interfaces. egiga0 (which also had the network routing) is on my DMZ (192.168.1.x), whereas egiga1 was on LAN (192.168.0.x).

My LAN is not allowed to connect the net. It can connect only through a URL filtering proxy residing on the gateway. DMZ hosts can connect to the internet.

As I’ve described in my previous posts I had brought the egiga1 interface to work in active failover mode, just to reset things in networking, but after a reboot I was no longer able to connect at all to the box over HTTP.

Tried whatever I could over SSH: compared /etc settings between my two NAS boxes (the second resides strickly in the LAN) but to avail. The LAN-only box did allow me to connect over plain http, whereas the external one did not. And both of them I could not connect over https.

My client pc is on the LAN (192.168.0) and as I said all my attempts to connect over http/https to the box failed miserably.

Then I decided to try accessing the DMZ ip from a system also in DMZ. And this time it worked! Specifically, I was presented with the login page, but the URL was not the DMZ ip of the system, but a special of the following form

https://device-local-anidofsomesort.remotewd.com:8543/

device-local-anidofsomesort.remotewd.com resolves to the (private) ip of the DMZ interface! I presume that the device registers itself (if it has internet access) to remotewd.com to accomplish that. I presume that the advantage of this hack is that a home user can connect to his box using a reliable certificate. The disadvantage is that a user behind a protected network (like the other box residing in my lan) can not access the box over https (whereas a self-signed certificate would do the job nicely)!

And that’s issue 1.

Issue 2: in doing this, WD gets information about my network topology (DMZ address/subnet). This is outrageous, especially considering that (a) our environment is striving for GDPR compliance, (b) I’ve opted out of all call-home communication with WD!!!. I can not stress hard enough how dangerous is for WD to gather that sort of information. If you are going to provide this “facility” have the user opt-in for it, instead off opting-out or, even worse, not offering any workaround like self-signed certificates!

Issue 3 possibly explains why I could not connect to the problematic box at all. I guess that the box had registered itself alright with its special device-local-anidofsomesort.remotewd.com resolving to a 192.168.1.14 address. This did not explain why I was not able to connect to it from the LAN side (192.168.0).

I did stumble into some older (5.07.118) release notes, stating the following:

Modified IP address filter of web dashboard to allow access from computer within the same subnet if user is using IP address that are not within the private IP ranges defined by RFC1918 of the Internet Engineering Task force

If this modification blocks my lan pc from viewing the DMZ system, then again it’s clearly a bug, since this “functionality” should not affect users whose ip addresses are clearly in the RFC1918 IP ranges!

Issue 4 related to the issues above. On my other, LAN-only box I can connect to the box only via http. No https at all. Possible cause: the box can not connect to the internet to get this pseudo-DNS (direct connection to inet from LAN is allowed only through a filtering proxy; which the box does not understand). Again, we need some way to either disable https completely (dangerous) or allow self-signed certificates (better)!

PS: I’m now having a two day downtime. Noone even cared to address my support ticket. Yesterday after waiting 30 minutes for chat support, when my turn came the chat was dropped for heaven’s sake/

I’m really furious with WD for this level of incompetence. They are definitely going to be ruled out for future procurement. In the price range, I’ll definitely stick with QNAP/Synology.

13

Forgot the worst issue 5. After finally being able to login in, I receive this screen on my iSCSI volume screen:

εικόνα
εικόνα733×131 2.13 KB

WTH is going on? I can’t tell why it is creating my existing iSCSI volume! WHERE’S MY DATA!

14

And yet another update: after changing the LAN interface to another LAN address and back, the device-local-anidofsomesort.remotewd.com pseudo-address now reflects the LAN address and not the DMZ one… Jezaz!

15

Regarding the iSCSI issue, I’ve found the following in /var/log/user/log:

user.log:2021-02-04T11:08:38.943920+02:00 di=1UhFMtyhjh  7 wdnas xmldbc: [../comlib/libxmldbc.c:189]__open_socket: Cound not connect to unix socket: /var/run/xmldb_sock_iscsi.
user.log:2021-02-04T11:08:38.958735+02:00 di=1UhFMtyhjh  7 wdnas xmldbc: cmd=iscsictl--deinit
user.log:2021-02-04T11:08:39.333697+02:00 di=1UhFMtyhjh  7 wdnas xmldbc: [../comlib/libxmldbc.c:189]__open_socket: Cound not connect to unix socket: /var/run/xmldb_sock_iscsi.
user.log:2021-02-04T11:08:39.348415+02:00 di=1UhFMtyhjh  7 wdnas xmldbc: cmd=iscsictl--init
user.log:2021-02-04T11:29:46.262949+02:00 di=1UhFMtyhjh  7 wdnas xmldbc: [../comlib/libxmldbc.c:189]__open_socket: Cound not connect to unix socket: /var/run/xmldb_sock_iscsi.
user.log:2021-02-04T11:29:46.277953+02:00 di=1UhFMtyhjh  7 wdnas xmldbc: cmd=iscsictl--init
16

Aaaaand after a reboot it switches to the DMZ address X’D. Talking about reliable and consistent configurations here!

17

Issue 6: the box is not visible now via SMB on LAN! It does not respond to pings as well. SSH’ing shows that egiga1 has lost its ip configuration. From web admin though it shows up, active and with correct settings!

Re-saving lan2 (egiga1) settings makes it visible again (ping, SMB shares etc). Until the next reboot, whereas the settings are lost again!!!

18

One step forward, two steps backward: “fixed” this by disabling iSCSI on the box, re-entering the LAN ip, and re-enabling iSCSI on the box. But it shows as portal address the DMZ (LAN1 - egiga0) and not the LAN (LAN2 - egiga1) one! I opened my LAN to DMZ firewall and also changed the SCSI initiator details on my Window server to mitigate the issue, but a clear resolution is needed. Why can’t I know have the LAN2 address for iSCSI? Why does LAN2 get eradicated on each reboot?

19

The clearest complaint on this topic I have read.

People using a NAS box are not looking for a “cloud” solution. OneDrive and DropBox serve that need quite well. For those seeking NOT to use a web service, the level of access this NAS maintains with outside servers is not what those type of users want.

Me? I have not turned on the OS/5 box for a few weeks. . .my os/3 box seems to be getting the job done.

20

Thank you for your kind words. I’ve closed around 20 hours trying to get this thing up and running and I’ve become incomprehensible (and furious) in the process. This is not a home setup, but a business one (don’t ask me why I was given EX4100 to do the job a QNAP/Synology would have managed without a fuss).

I’ve opened a new thread to clarify things out, as well as a new clear-written ticket. I’m summarizing things in EX4100 with LAN1/LAN2 on different LAN segments: issues after OS 5 upgrade (also issue #210205-002609)

21

@carmik,

I think the best thing you can do under the circumstances, is to move the iSCSI volume off the NAS to somewhere else and then backup anything else that you want to keep and then perhaps try one of the procedures mentioned elsewhere in the forums for forcing a downgrade of the OS back to OS3. If you have logged these support tickets and are not getting a response, it is a clear indication that WD do not wish to respond, which is pretty much their MO.

Cheers,

JediNite

22

@JediNite thanks for your message. I am seeing a non-existent customer support here, leaving users to help each other on their own. Which might be ok for a FOSS product, but not for a closed, paid one…

I have other issues to tackle at work, leaving me no time to follow a downgrade procedure. That’s why I’m trying to reach someone from WD to have a look at this remotely.

What’s this co-browse thing? I only see a number but nothing happens…

23

Not sure on this one sorry!! Anyone else ?