Netgear ReadyNAS 316
Links
- http://support.netgear.com/product/RN31600
- http://support.netgear.com/product/ReadyNAS-OS6
- http://www.netgear.com/business/products/storage/readynas/readynas-desktop.aspx
- http://www.readynas.com/
- X-RAID
- ReadyNAS Developer’s Corner
- ReadyNAS Downloads
- X-Raid calculator
General
Initial login: admin/password
If SSH activated, root has same pwd as admin.
Update FW Alerts:
- Email: recipient email
- Advanced settings/SMTP Server: can be 127.0.0.1 if you've installed Exim (see below)
- Advanced settings/From: sender email
- Then don't forget to "Apply" after having sent successfully a test message
(since reinstall with 6.2.2, sending test message failed but still I received the test mail...)
Certificat HTTPS
To change it, cf http://readynas.sphardy.com/2010/10/installing-ssl-certificate-on-your_7476.html
- Create directory /etc/frontview/apache/addons/
- Copy CACert root cert (PEM format) in /etc/frontview/apache/addons/root.crt
- Copy CACert intermediate cert (PEM format) in /etc/frontview/apache/addons/class3.crt
- Merge your RSA cert & key in a single PEM file and replace /etc/frontview/apache/apache.pem by yours
- Avoid frontview or fw updates to overwrite it (not sure if it could harm fw upgrade...):
chattr +i /etc/frontview/apache/apache.pem
- Create a file /etc/frontview/apache/addons/ssl.conf with
SSLCACertificateFile /etc/frontview/apache/addons/root.crt SSLCertificateChainFile /etc/frontview/apache/addons/class3.crt
- Tell Apache to reload its config
killall -HUP apache2
hosts
Complete /etc/hosts
Debian
System is a Debian Wheezy
Edit /etc/apt/sources.list and add non-free:
deb http://mirrors.kernel.org/debian wheezy main non-free apt-get update apt-get install dialog apt-get install mc screen binutils sshfs pv netcat encfs man python htop iotop p7zip p7zip-full unrar git sudo
What is not available:
- luks? missing some support in kernel?
apt-get install exim4 bsd-mailx dpkg-reconfigure exim4-config
3. mail sent by smarthost; no local mail System mail name: yobi.be IP-addresses to listen on for incoming SMTP connections: 127.0.0.1 Other destinations for which mail is accepted: Visible domain name for local users: yobi.be IP address or host name of the outgoing smarthost: smtp.isp.xxx Keep number of DNS-queries minimal (Dial-on-Demand)? n Split configuration into small files? y Root and postmaster mail recipient: phil
Complete /etc/email-addresses
backuppc (old)
apt-get install backuppc libfile-rsyncp-perl libio-dirent-perl
Small issue because Apache is not running as the usual www-data but admin user:
chgrp admin /etc/backuppc/* chgrp admin /usr/lib/backuppc/cgi-bin/index.cgi chmod u+s /usr/lib/backuppc/cgi-bin/index.cgi
Set backuppc password:
htpasswd /etc/backuppc/htpasswd backuppc
Move pool to the big partition, preserving hard links
/etc/init.d/backuppc stop cp -a /var/lib/backuppc /home rm -rf /var/lib/backuppc ln -s /home/backuppc /var/lib/backuppc /etc/init.d/backuppc start
If you want to encrypt backup pool, you can alternatively do:
/etc/init.d/backuppc stop cp -a /var/lib/backuppc /home/backuppc.orig rm -rf /var/lib/backuppc mkdir /home/.backuppc adduser backuppc fuse mkdir /var/lib/backuppc chown backuppc.backuppc /var/lib/backuppc encfs --public /home/.backuppc /var/lib/backuppc
We need hardlinks, so use "standard" settings of encfs, no external IV chaining!
And because it will be accessed also by Apache, even if through some setuid, we need --public
su -s /bin/bash backuppc $ rsync -avH /home/backuppc.orig/ /var/lib/backuppc rm -rf /home/backuppc.orig /etc/init.d/backuppc start
If you choose encryption, it cannot start automatically anymore:
for i in /etc/rc*.d/S*backuppc; do mv $i ${i/S/K};done update-rc.d backuppc defaults systemctl --system daemon-reload
And from now on, use scripts to start/stop manually:
#!/bin/bash encfs --public /home/.backuppc /var/lib/backuppc && /etc/init.d/backuppc start
#!/bin/bash /etc/init.d/backuppc stop fusermount -u /var/lib/backuppc
Visit https://readynas/backuppc
Default backup of localhost /etc will fail due to some read access issues, we can ignore them by tuning the corresponding TarClientCmd and appending to it:
--ignore-failed-read
Transmission
There is a readynas app, but better to use the Debian one if you want to tune it.
apt-get install transmission-daemon /etc/init.d/transmission-daemon stop
Edit /etc/default/transmission-daemon:
ENABLE_DAEMON=0
Create /data/Transmission/info/settings.json
# cf https://trac.transmissionbt.com/wiki/EditConfigFiles "download-dir":... "incomplete-dir":... "rpc-password": "your_password", # note that it will be encrypted next time automatically
chown -R phil.users /data/Transmission/info
transmission-start.sh:
#!/bin/bash exec su -s /bin/bash phil -c "/usr/bin/transmission-daemon --config-dir /data/Transmission/info/ --logfile /data/Transmission/info/logfile --log-info"
transmission-stop.sh:
#!/bin/bash exec su -s /bin/bash phil -c "killall transmission-daemon"
If you've some transmission settings to transfer from another machine:
- settings.json is in /etc/transmission-daemon/settings.json
- other stuffs (blocklists, resume, torrents,...) is in /var/lib/transmission-daemon/info/
To fix .resume files from another location, here from /shares/.... to /data/....: file is bencoded but a few bash lines are enough
#!/bin/bash
FILE="$1"
OLDDESTSIZE=$(cat "$FILE"|cut -f6 -d:|head -n1|sed 's/destination//')
OLDDEST="/shares"
NEWDEST="/data"
NEWDESTSIZE=$(($OLDDESTSIZE-${#OLDDEST}+${#NEWDEST}))
sed -i "s#:destination[0-9]\+:${OLDDEST}#:destination${NEWDESTSIZE}:${NEWDEST}#" "$FILE"
chown phil:users "$FILE"
Changing tracker port:
./transmission-stop.sh
cd /data/Transmission/info/torrents
for i in *; do sed -i '/^d8:/s#announce69:http://mytracker:8880#announce70:http://mytracker:56969#' "$i"; done
./transmission-start.sh
To run it under another user:
Edit /etc/init.d/transmission-daemon -> USER=joe, then:
chown -R joe.users /var/lib/transmission-daemon chown -R joe.users /etc/transmission-daemon systemctl --system daemon-reload /etc/init.d/transmission-daemon start
Transgui / Transmission options / Network / Incoming port <> router firewall?
YAMJ
To server YAMJ, we can run Apache on another port
# cat /etc/apache2/sites-available/yamj <VirtualHost *:8000> ServerAdmin webmaster@localhost DocumentRoot /data/path/to/yamj/Jukebox/ <Directory /data/path/to/yamj/Jukebox/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/yamj-error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog ${APACHE_LOG_DIR}/yamj-access.log combined </VirtualHost>
Add to /etc/apache2/ports.conf
Listen 8000
Then
a2ensite yamj service apache2 reload
To be able to run YAMJ locally:
apt-get install openjdk-7-jre-headless
Android
Maintenance
WARNING this section is for "power users", some notes after I went through some troubles with my NAS.
Don't trust anything written here, don't try anything yourself, contact Netgear support in case of problems!
In two words, my NAS started behaving strangely then refused to boot, it appeared that the cause was a faulty RAM.
Locale console
You can plug a HDMI screen and a keyboard, you'll get access to the BIOS and boot sequence
If you press the reset button (small hole on the back) and maintain it pressed while booting till "Boot Menu" appears on the LCD screen you'll reach... the boot menu. Cf http://kb.netgear.com/app/answers/detail/a_id/23005
From here, several options, use the touchpad up/down & ok to select one:
- Memory test -> runs memtest86 with some summary on the LCD but it's much more confortable with a HDMI screen plugged.
- OS reinstall. Reinstalls the firmware from the internal flash to the disks. Use the OS reinstall boot mode when the system crashes and corrupts some configuration files. OS reinstall boot mode also resets some settings on your storage system, such as Internet protocol settings and the administrator password, to defaults.
So default access is root/password
- Volume read only. Mounts a volume as read-only. Use this option when you are attempting to rescue data off a disk during a disaster recovery.
- Disk Test. Performs an offline full disk test. This process can take four hours or more, depending on the size of your disks.
Personally I prefer to run smartmontools myself, see below
- Tech support. Boots into a low-level diagnostic mode. Use the tech support boot mode only when a NETGEAR technical support representative instructs you to do so.
See below
- Factory default. WARNING: The factory default reboot process resets the storage system to factory settings, erases all data, resets all defaults, and reformats the disk to X-RAID2.
Because of my faulty RAM that corrupted my filesystems, I had to go for this last option once I've backed up all my data.
Tech mode
Is one of the special boot modes.
WARNING You're not supposed to use it yourself but, well, on Internet I could find a lot of things, including the support telnet password... So, here it is:
In that mode it boots on the image contained in the flash so this works even if the HDD are completely out of order.
It launches a telnet and some tunneling to Netgear so they can operate remotely.
Login: root / infr8ntdebug
You can display processes (ps) and kill the tunnel back to Netgear if you want more privacy.
1002 root 0 SW [kworker/0:2] 1006 root 4864 S raidard 1014 root 3084 S ifplugd -i eth1 1113 root 3076 R /usr/sbin/telnetd 1137 root 37464 S /usr/bin/rnutil remote_access -b 1139 root 3072 S /bin/sh -c /bin/sh 1140 root 3084 S /bin/sh 1141 root 9212 S {dropbearmulti} dropbear -E -F -p 127.0.0.1:1022 1243 root 9276 S {dropbearmulti} dbclient -y -T -K 60 -p 443 -R *:513 # cat /proc/1243/cmdline dbclient -y -T -K60 -p443 -R *:51302:127.0.0.1:1022 tunnel@shells.readynas.com FW=6.2.1 SERIAL=<myserial> MAC=<myMAC> PORT=51302 <myserial>
Poking:
# ssh -p443 tunnel@shells.readynas.com tunnel@shells.readynas.com's password: infr8ntdebug Greetings, Professor Falken. Would you like to play a game?
There is a dropbear binary so you can launch a small ssh server, helpful to initiate some file transfers if needed:
# dropbear
WARNING the commands enumerated here are what I tried, but probably not what is the best to do
/dev/md0 contains the OS
/dev/md1 is the swap
/dev/md127 contains /data
But before that we need to assemble the arrays:
# mdadm --assemble --scan
(There is also /usr/bin/rnutil start_raids -v supposed to do the same, maybe more like mounting the partitions?)
Then e.g. to mount the system partition:
# mount /dev/md0 /sysroot
To mount it desperately:
# mount -o ro,recovery /dev/md0 /mnt
To watch out a Raid resync (and wait for it to complete):
# cat /proc/mdstat Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md127 : active raid5 sda3[4] sdd3[3] sdc3[2] sdb3[1] 11706499968 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] [>....................] resync = 1.8% (71255944/3902166656) finish=1418.8min speed=44998K/sec
Btrfs:
# btrfs filesystem show /mnt Label: <serial>:root uuid: 12345678-1234-1234-1234-123456789abc Total devices 1 FS bytes used 854.89MiB devid 1 size 4.00GiB used 2.68GiB path /dev/md/0
To attempt to fix it:
# btrfs check --repair /dev/md0
To format(!!!) it:
# mkfs.btrfs -L <serial>:root -f /dev/md0 WARNING! - Btrfs v0.20-rc1 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label <serial>:root on /dev/md0 nodesize 16384 leafsize 16384 sectorsize 4096 size 4.00GiB Btrfs v0.20-rc1
Hmm, cool warnings...
For data, we get (if mounted at /mnt)
# mount -o ro /dev/md/data-0 /mnt # btrfs filesystem show /mnt Label: <serial>:data uuid: 12345678-1234-1234-1234-123456789abc Total devices 1 FS bytes used 6.86TiB devid 1 size 10.90TiB used 7.29TiB path /dev/md/data-0 # btrfs subvolume list /mnt
Forensics:
If filesystem is severly damaged an option is to dd the partition to another disk then from another computer attempt to extract files from the broken btrfs to the current directory:
$ sudo btrfs restore -x -v /mnt/md0.img .
Back to our tech mode...
Note that btrfs version in the OS is more recent/complete than the one in the fw so better to pivot to it if possible. Another reason to pivot is e.g. to run fw upgrade of HDD or any tool not present in the fw.
Official way if OS is intact is sth like "rnutil chroot", to be checked.
If the OS is destroyed, then there is one option:
Prepare a root image from the flash
If flash is not accessible:
rnutil toggle_flash
In regular OS this mounts /media/USB_FLASH_1, in tech mode I don't remember, you've probably to mount /dev/sde1 yourself
(wd5741 from http://download.wdc.com/sata/wd5741x32?v=2916)
firmware: from http://support.netgear.com/product/ReadyNAS-OS6 get Software Version 6.x.x (x86)
unzip ReadyNASOS-6.4.1-x86_64.zip
binwalk ReadyNASOS-6.4.1-x86_64.img DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 16384 0x4000 POSIX tar archive (GNU), owner user name: "root", owner group name: "root"
dd if=ReadyNASOS-6.4.1-x86_64.img bs=$((0x4000)) skip=1 | tar -xv root.tlz
I don't remember if tar from this environment is able to decompress lzma, I made a root.tgz from another computer.
other# scp root.tgz root@readynas:/run/ # cd /run/sysroot # tar xzf ../root.tgz # mount -o bind /dev /run/sysroot/dev # mount -t proc none /run/sysroot/proc # mount -t sysfs sys /run/sysroot/sys # chroot /run/sysroot # bash # # you're in! # ctrl-d # ctrl-d
We can use this environment e.g. to reflash HDDs if needed
other# scp root.tgz root@readynas:/run/ other# scp wd5741x64 root@readynas:/run/ # umount /media/hdd # umount /sysroot # mdadm --stop /dev/md0 # mdadm --stop /dev/md1 # mdadm --stop /dev/md127 # cd /run/sysroot # tar xzf ../root.tgz # mount -o bind /dev /run/sysroot/dev # mount -t proc none /run/sysroot/proc # mount -t sysfs sys /run/sysroot/sys # cp ../wd5741x64 /run/sysroot/bin/ # chroot /run/sysroot # bash # wd5741x64 -d? # wd5741x64 -d0 # was not needed # wd5741x64 -d1 # wd5741x64 -d2 # wd5741x64 -d3 # ctrl-d # ctrl-d
I had to reflash 3 of my 4 WD Red 4T Hdds because "smartctl -a" showed an alarming Load_Cycle_Count (300.000 while manufacturer datasheet mention 600.000 as life limit, a fw bug apparently that the new fw fixes by waiting longer before deciding to park heads)
Brief smartmontools recap:
smartctl -a /dev/sda
Initiate long test:
smartctl -t long /dev/sda
Check status of test:
smartctl -l selftest /dev/sda
RAM & backups
Faulty original RAM was:
Sku's M3SW-2GHJCCN9 Product Description InnoDisk DDR3 SODIMM - DDR3 - 2 GB - SO DIMM 204-pin Capacitance 2GB Memory Type DDR3 SDRAM - SO DIMM 204-pin Upgrade Type System specific Data Integrity Check Non-ECC Speed 1333 MHz (PC3-10600) Latency CL9 Services On-Die Termination (ODT), Serial Presence Detect (SPD), unbuffered Voltage 1.5 V Manufacturer Warranty Limited lifetime warranty
I replaced it with what I had:
SODIMM DDR3 4 GB 1600Mhz PC12800
But according to BIOS it runs at max 1033MHz anyways
As I made part of the backups with the faulty RAM, I had to check my copies once the new RAM was installed:
cd /data/ for i in *; do find $i -type f -exec md5sum {} \; > /run/data_$i.md5;done
Then after some diffing I had a lost of files to backup again: todo.t
tar -c -f /path/to/backup_extra.tar -T /todo.t -v
Note that I was a bit reluctant but a HDD can be inserted in an empty tray if it's already formatted, it won be magically integrated into the X-Raid and it's much faster for massive file transfers than USB3 (not talking about the USB2 below the door)