Netgear ReadyNAS 316

From YobiWiki
Jump to navigation Jump to search



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 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

  • 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


Complete /etc/hosts


System is a Debian Wheezy
Edit /etc/apt/sources.list and add non-free:

deb 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:
IP-addresses to listen on for incoming SMTP connections:
Other destinations for which mail is accepted: 
Visible domain name for local users:
IP address or host name of the outgoing smarthost: 
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:

encfs --public /home/.backuppc /var/lib/backuppc && /etc/init.d/backuppc start
/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:



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:


Tell systemd to ignore transmission:

systemctl disable transmission-daemon.service
systemctl stop transmission-daemon.service

Create /data/Transmission/info/settings.json

# cf
"rpc-password": "your_password", # note that it will be encrypted next time automatically
chown -R  phil.users /data/Transmission/info

exec su -s /bin/bash phil -c "/usr/bin/transmission-daemon --config-dir /data/Transmission/info/ --logfile /data/Transmission/info/logfile --log-info"

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

OLDDESTSIZE=$(cat "$FILE"|cut -f6 -d:|head -n1|sed 's/destination//')
sed -i "s#:destination[0-9]\+:${OLDDEST}#:destination${NEWDESTSIZE}:${NEWDEST}#" "$FILE"
chown phil:users "$FILE"

Changing tracker port:

cd /data/Transmission/info/torrents
for i in *; do sed -i '/^d8:/s#announce69:http://mytracker:8880#announce70:http://mytracker:56969#' "$i"; done

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?


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

	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

Add to /etc/apache2/ports.conf

Listen 8000


a2ensite yamj
service apache2 reload

To be able to run YAMJ locally:

apt-get install openjdk-7-jre-headless


After upgrade, things to do/to check:

  • Make sure no transmission is running
pgrep transmission
  • Start our transmission
  • Check if Apache runs on secondary port with yamj, if not it's probably the port to add again:
/etc/apache2/ports.conf: Listen 8000
service apache2 reload
  • Start our bindings



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

Boot menu

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
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
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: FW=6.2.1 SERIAL=<myserial> MAC=<myMAC> PORT=51302 <myserial>


# ssh -p443'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 add a new disk, here sdb: first copy partition table from sda to sdb and randomize UUIDs on sdb:

# sgdisk --backup=table /dev/sda
# sgdisk --load-backup=table /dev/sdb
# sgdisk -G /dev/sdb

Then add the new partitions to the respective arrays:

# mdadm --manage /dev/md0 --add /dev/sdb1
# mdadm --manage /dev/md1 --add /dev/sdb2
# mdadm --manage /dev/md127 --add /dev/sdb3

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 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! - see 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

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
firmware: from get Software Version 6.x.x (x86)

binwalk ReadyNASOS-6.4.1-x86_64.img
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)