This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
5 days ago, my ReadyNAS started having network connection issues (coincident with Mirai DDOS attacks?) 😛 I first noticed when my backup service complained that it hadn't heard from the device in a few days.
RAIDar saw the readynas at 192.168.1.5. When I browsed into the admin page, I didn't see any error logs, but the network showed as disconnected. (Strange, since I was connected through my web browser.) I noticed the mac address was one digit off from what I thought it should have been. The ReadyNAS was also set to pull an address automatically from DHCP. I swear it used to be configured to have a static IP address. I tried to manually configure it to 192.168.1.5, but it wouldn't let me save the changes from the web interface. So I rebooted the ReadyNAS.
When it came back up, the IP address was 192.168.168.168. I read online that this means it wasn't able to get an IP address from DHCP. I swapped ports on the router, swapped cables, tried a direct connection to my PC (I changed my PC's IP address to 192.168.168.100, subnet mask to 255.255.255.0). When directly connected, I can ping the NAS, but I can't connect to the admin page. Chrome returns connection refused. I tried logging in through SSH (root@192.168.168.168) and similarly got a connection-refused response. All the status lights are green in raidar. Now I can't access anything on my NAS.
Running firmware ver 4.2.28. It's been one year since someone from support reinstalled my OS remotely for me. It's pretty much been working without issues, and I haven't made any changes to the system.
I copied the network/interfaces file from the tech support partition into the normal boot partition and rebooted. Figured a blank configuration file can't be a good thing. Success! The machine pulled a new IP address from DHCP, and I could log back into frontview. 🙂
From there, I just had to reenable CIFS and reinstall EnableRootSSH. All my shares are accessible again, and crashplan seems to be running and synced up. Although the crashplan log file mentions something about not being able to install an update. This might be what caused my partition to fill up, but it's another problem for another time...
Thanks again, everybody, for all the help!
btw, these are the very helpful instructions I followed to get in through tech support mode and clear out some space in the OS partition.
That makes sense. It's happened to me before when crashplan filled up my OS partition with log messages. I thought I had changed the settings so that the logs were written to the main volume, but maybe there's something else clogging things up.
I'd like to have tech support fix it, but since I can't change the IP address, I'm not sure how anyone can even log in remotely. I think I found some instructions online to log in in tech support mode. I'll probably have to give those a try.
I noticed the mac address was one digit off from what I thought it should have been. The ReadyNAS was also set to pull an address automatically from DHCP. I swear it used to be configured to have a static IP address.
It sounds like, in the midst of all this, you swapped ehternet ports, as eth1's MAC is one more than eth0. And your static adddress would be for the original port. Note that setting a static port on the NAS is not a good idea, at least not unless you also reserve it on your router. If the NAS is off (or offline, as it was here) and another device grabs the static address, problems arrise. Of course, with a reserved address on the router, the static address on the NAS is moot.
This is probably not the main cause of the problem, which likely s a full OS partition, as already diagnosed,but it added to the confusion.
I noticed the mac address was one digit off from what I thought it should have been. The ReadyNAS was also set to pull an address automatically from DHCP. I swear it used to be configured to have a static IP address.
It sounds like, in the midst of all this, you swapped ethernet ports, as eth1's MAC is one more than eth0. And your static adddress would be for the original port.
That's a likely explanation. It also applies to address reservation in the router, since that depends on the MAC address of the ethernet port.
Hmm..makes sense. I probably did swap the cable during my debugging.
So I managed to get into tech support mode and clear up 2.6 GB on the OS partition (crashplan had filled the space with update files). On rebooting the machine, raidar still reports 192.168.168.168 as the IP address. Strangely, the front LED panel of the readynas reports 192.168.1.5, which was my original statically-assigned IP. DHCP starts at over 100 on my network, so no conflicts. I can't log in through ssh or the web-based admin interface on either IP. I get a connection refused error. I can, however, ping the machine on 192.168.168.168.
I poked around a bit while I was logged in to see where the network was configured, but I'm not familiar enough with how this system to attempt changing the configuration files manually.
In tech support mode, the readynas did manage to get an IP address through DHCP, so I guess calling tech support is still an option. I really hope that they can fix it without reinstalling the OS. I don't want crashplan to resync 3+ TB of data over the internet again. Ugh...
Thanks for all the help so far. If there's anything else I can try, please let me know.
I copied the network/interfaces file from the tech support partition into the normal boot partition and rebooted. Figured a blank configuration file can't be a good thing. Success! The machine pulled a new IP address from DHCP, and I could log back into frontview. 🙂
From there, I just had to reenable CIFS and reinstall EnableRootSSH. All my shares are accessible again, and crashplan seems to be running and synced up. Although the crashplan log file mentions something about not being able to install an update. This might be what caused my partition to fill up, but it's another problem for another time...
Thanks again, everybody, for all the help!
btw, these are the very helpful instructions I followed to get in through tech support mode and clear out some space in the OS partition.
It's been a couple weeks of normal use. I think I was lucky... nothing else seems wrong.
Although... I've noticed that Crashplan hasn't been able to update to the newest version. (I might have to update to java 8.) It seems to download a new 40MB update file every half hour or so. I can see why the OS partition filled up so quickly.
Although... I've noticed that Crashplan hasn't been able to update to the newest version. (I might have to update to java 8.) It seems to download a new 40MB update file every half hour or so. I can see why the OS partition filled up so quickly.
Crashplan now installs its own Java.
There is a certificate issue that blocks the upgrade - Try logging in with ssh and entering
cd $home
echo "check_certificate = off" >.wgetrc
This was all I needed to do, but some others have had more issues after they did this.
I've just given up on running crashplan on the NAS. It's worked well these last 6 years or so, but it seems like there's something that always needs fixing. Being a linux noob, it's too much work for me. Plus I've read reports on these forums that code42 will stop allowing crashplan to run headless. I've switched over to mounting the NAS on my mac and running crashplan there. So far, so good. Only "61 days" remaining to finish de-duplicating... 😛
