My old NAS that I use for backups is now over 10 years old, and while it
still works and faithfully backs-up my files every night, it has an always
increasing probability to fail.
I decided to replace it with a Buffalo Linkstation 210, that offers 2 TB of
space for 140 EUR, making it cheaper than building my own device, at the risk
of not being able to use it the way I want it, being a commercial device that
wasn't designed with my needs in mind.
The way I want to use the NAS is that it boots automatically at a given
time, after which the backup script on the desktop starts, transfers the
needed files, and puts the NAS to sleep mode again. That last feature was
available on my previous device, but not anymore on the LS210. Hence the need
to make it do my bidding.
Moreover, the Web UI for administrating the LS210 is horribly slow on my
desktop due to bad Javascript code, so the less I have to use it, the better.
The device
The way to gain SSH access seems to vary depending on the exact version of the
device and the firmware. Mine is precisely a LS210D0201-EU device with
firmware version 1.63-0.04, bought in January 2017.
Initial setup
I found instructions on
the nas-central.com forum. It relies on a Java tool called
ACP_COMMANDER
that apparently uses a backdoor of the device that is used for firmware
updates and whatnots, but can apparently be used for running any kind of shell
command on the device, as root, using the device's admin user's password.
Let's assume $IP is the IP address of the device and "password" is the
password of the admin user on the device (it's the default password).
You can test that ACP_COMMANDER works with the following command that runs
uname -a on the device:
java -jar acp_commander.jar -t $IP -ip $IP -pw password -c "uname -a"
It will output some amount of information (including a weird message about
changing the IP and a wrong password ), but if you find the following in the
middle of it, it means that it worked:
>uname -a
Linux LS210D 3.3.4 #1 Thu Sep 17 22:55:58 JST 2015 armv7l GNU/Linux
Starting the SSH server is then a matter of
- enabling the SSH feature (which, on this cheap model, is disabled by
default),
- starting the SSH server,
- changing root's password to "root" so that we can login (the password can be
changed to something more secure later).
This is achieved through the following commands:
java -jar acp_commander.jar -t $IP -ip $IP -pw password -c "sed -i 's/SUPPORT_SFTP=0/SUPPORT_SFTP=1/g' /etc/nas_feature"
java -jar acp_commander.jar -t $IP -ip $IP -pw password -c "/etc/init.d/sshd.sh start"
java -jar acp_commander.jar -t $IP -ip $IP -pw password -c "(echo root;echo root)|passwd"
On some older version of the firmware, root login was disabled in SSH, and
needed to be allowed with
java -jar acp_commander.jar -t $IP -ip $IP -pw password -c "sed -i 's/#PermitRootLogin/PermitRootLogin/g' /etc/sshd_config"
but that is not the case on my device.
Once this is done, I can run
ssh root@$IP
and login with password "root" (which was set earlier).
One nasty feature of the device is that the
/etc/nas_feature file gets
rewritten on each boot through the initrd. One last step is then to edit
/etc/init.d/sshd.sh and to comment out near the beginning of the file the
few lines that check for the SSH/SFTP support and exit in case SSH is not
supported:
#if [ "${SUPPORT_SFTP}" = "0" ] ; then
# echo "Not support sftp on this model." > /dev/console
# exit 0
#fi
According to a comment
on the nas-central forum,
“The /etc/nas_feature is restored on each reboot,
so sshd does not run on boot. Even if you change the init script.”
but I
found this not to be true.
I checked that this setup really resists reboots, by logging in as root and
typing reboot. SSH access was still possible after the device had restarted.
Going further
It was then possible to setup SSH access using keys; RSA and ECDSA are
supported but not ED25519.
One missing feature is the sudo command, but I can live without it I guess.
I have then setup the device to wake up at a given time (through the “Sleep
timer” feature in the administration Web UI). It is then possible to put the
device to sleep by running as root
PowerSave.sh standby
The command is located in
/usr/local/sbin, and this path is not available
for non-interactive logins, so I wrote the following wrapper script to
shutdown the device:
#!/bin/sh
ssh root@$IP 'bash -l -c "PowerSave.sh standby"'
After having been put into standby, the device will then start automatically
on the set time, or when the “function” button on the back is pressed.
