Thanks, I'll try and do that but first I want to make a copy of what is on the system, but I can't access via ssh.. I suspect there is some firewall rule blocking access. The system was configured with an IP of 192.168.0.1 but I've changed it to 192.168.1.7 so maybe the firewall rules may need changing.
root@nas:~/ cat /etc/firewall.user
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
# Internal uci firewall chains are flushed and recreated on reload, so
root@nas:/# cat /etc/firewall.user
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.
iptables -I zone_lan_input -j REJECT
#iptables -I zone_lan_input -j LOG
iptables -I zone_lan_input -p icmp -j ACCEPT
iptables -I zone_lan_input -p igmp -j ACCEPT
# Allow torrent clients to initiate connections (transmission)
iptables -I zone_lan_input -p tcp --dport 6881:6999 -j ACCEPT
iptables -I zone_lan_input -p udp --dport 6881:6999 -j ACCEPT
iptables -I zone_lan_input -s 192.168.0.128/25 -j ACCEPT
iptables -I zone_lan_input -s 192.168.0.254 -j REJECT
# Allow ssh and rsync access from gw
iptables -I zone_lan_input -p tcp -s 192.168.0.254 --dport 22 -j ACCEPT
iptables -I zone_lan_input -p tcp -s 192.168.0.254 --dport 873 -j ACCEPT
# Allow NFS from gw
iptables -I zone_lan_input -p tcp -s 192.168.0.254 --dport 32780 -j ACCEPT
iptables -I zone_lan_input -p tcp -s 192.168.0.254 --dport 2049 -j ACCEPT
root@S07:/# ping -c2 192.168.1.7
PING 192.168.1.7 (192.168.1.7): 56 data bytes
64 bytes from 192.168.1.7: icmp_seq=0 ttl=64 time=0.291 ms
64 bytes from 192.168.1.7: icmp_seq=1 ttl=64 time=0.253 ms
--- 192.168.1.7 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.253/0.272/0.291/0.019 ms
root@S07:/# arp 192.168.1.7
? (192.168.1.7) at 00:10:75:26:64:91 on em0 expires in 1176 seconds [ethernet]
root@S07:/# telnet 192.168.1.7:21
192.168.1.7:21: hostname nor servname provided, or not known
root@S07:/# ssh -p 2222 admin@192.168.1.7
ssh: connect to host 192.168.1.7 port 2222: Connection refused
root@S07:/# ssh admin@192.168.1.7
ssh: connect to host 192.168.1.7 port 22: Connection refused
root@S07:/# ssh 192.168.1.7
ssh: connect to host 192.168.1.7 port 22: Connection refused
root@S07:/# nmap -sT 192.168.1.7
Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-27 12:08 UTC
Warning: 192.168.1.7 giving up on port because retransmission cap hit (10).
I do have serial access so am able to change the configuration, just don't know how to enable ssh for root on port 22...
Most likely you’ve done something since to break it again. You clearly had it running 6 days ago, with access to LuCI.
You really should take the time, as previously requested, to understand the basics of networking and the very basics of Linux-based OS system administration before you proceed.
This is a GoFlex Net. I've never had one of these and only just got it yesterday, and have had nothing to do with configuring it (apart from changing IP address) or installing any software on it.
The you should never have run opkg to try to upgrade it, eh?
What's stopping you? Use of skills in reading and comprehending directions before taking action. Over-reliance on these forums to spoon-feed you personalized directions.
Right now, what you are trying to do is well past your apparent understanding of Linux-based OSes in general, and OpenWrt in specific.
I think you would be greatly benefited by purchasing a well-supported device with a relatively fool-proof recovery method. I recommend something like the GL.iNet AR300M-Lite, which is now supported in snapshots[1]. That device has a very good U-Boot, for which GL.iNet has included a web-based method for flashing an image, without use of serial. It is available for under US$20.
Use of such a device will let you better understand how to manage and troubleshoot an OpenWrt system.
While not quite a "12 o'clock flasher", you should stay out of editing config files, configure only using LuCI, and never write to the raw MTD devices.
You should also plan what you what to accomplish. That you're fixated on connecting via ssh to a device that you have serial access to is puzzling. One with sufficient skill should be able to ssh/scp from the device to any other connected device, without needing an SSH server running on the device.
[1] The AR300M-Lite should generally not be flashed with the AR300M (no -Lite) firmware that has been available for some time now. As the AR300M-Lite has a single Ethernet port and the "no -Lite" version has two, the AR300M firmware on a -Lite version will, on first boot or reset to defaults, likely be unreachable. This can be recovered by flashing the proper firmware version through U-Boot over its web-based interface.
So I've basically managed to get as far a the password prompt in ssh, but whatever password I use, or change via passwd in the serial console has no effect.