Using a Seagate rackmount NAS with Linux

Having recently obtained a Seagate Business NAS for use in my home network, I came across a few issues setting it up which I will explain here in case it helps anyone else one day.

Seagate 4-bay rackmount NAS. No, it doesn't have a short name.

Firstly, for those who haven't used these devices (codename "charger"), they are very nicely designed. They are essentially low-power PCs (Intel Atom CPUs), running a customised (but standard) PC BIOS, and the power supply even uses a standard ATX connector. The BIOS has limited configuration options, but is programmed to boot from a USB stick first, then each drive one by one. The USB stick is used to install the operating system, which is then mirrored across all disks via RAID1 so as long as one disk is present, the OS and all config options will be present.

Despite the device using a low-power CPU, it is easily able to max out the gigabit network connection without jumbo frames, using only around 30% CPU (for RAID0 - the CPU use may increase if RAID5/6 is used instead.) Jumbo frames can be enabled - the MTU can be set to 1500, or 2000 to 9000 in increments of 1000.

Installing NASOS

My device unfortunately didn't come with a NASOS install key thanks to it being second hand, so I had to create one myself. Sadly since the creation program is Windows only, I had to improvise.

Without going into too much detail (this is for experienced Linux users after all), here are the steps to create your own NASOS installation USB stick under Linux.

1. Figure out where the target USB stick is. This assumes the USB stick is /dev/sdd, so change as needed.
2. Partition the USB stick with a single FAT32 entry, making sure it is active so it can be booted.
   1. Run fdisk /dev/sdd
   2. Make a single primary partition, type "c" (FAT32 LBA)
   3. Make the partition active ("a")
3. Put a FAT32 filesystem on the new partition:

   mkfs.vfat /dev/sdd1

4. Make the USB stick bootable with Syslinux:

   syslinux --install /dev/sdd1
   

5. Copy the NAS OS install onto the USB stick:

   mkdir /mnt/nasos
   mount /dev/sdd1 /mnt/nasos
   cd /mnt/nasos
   tar xvf /path/to/windows/install/Data/charger-rescue_x.x.x.x_usb.tar
   

6. Edit /mnt/nasos/syslinux.cfg to set the USB partition ID.
   • Replace %UUID% with the UUID of the /dev/sdd1 partition
   • Run ls /dev/disk/by-uuid and look for /dev/sdd1 to find the UUID
7. Clean up:

   cd /
   umount /mnt/nasos
   rmdir /mnt/nasos
   

You should now have a USB stick that the NAS will boot to install the OS.

Connecting to the NAS under Linux

There are plenty of connectivity options however the two I will focus on are NFS and CIFS. Both of these have a number of drawbacks in the way they are implemented on this device:

NFS:

• When NFS is enabled, all shares become public
• No IP-address restrictions
• No UID/GID mapping
• Symlinks cause problems when the share is viewed via CIFS

CIFS:

• Can't create symlinks

Since CIFS only has one drawback, the easiest solution appears to be to use CIFS and get symlinks working. This will allow NAS shares to function much more like local storage.

Since the NAS is a standard Linux box, with CIFS services provided by Samba, this should be an easy fix. The easiest option would appear to be to mount the shares with the sfu option, which enables Microsoft's "Services for UNIX". Unfortunately while this mounts the share without any problems, symlinks still cannot be created for some reason, even though this is supposed to be possible.

To properly fix this problem, Samba needs to be configured to enable UNIX Extensions. This is disabled by default, and there is no option to enable it, so this is where things get interesting.

In order to enable UNIX Extensions, the NASOS needs to be modified. By default the Samba option for UNIX Extensions is hard-coded as off, so the code that produces smb.conf needs to be modified to turn it back on. Luckily, NASOS is relatively open so this is actually quite straightforward.

1. Log in to the NAS via SSH, with one of the accounts in the Administrators group.
2. Gain root access with sudo su and re-enter the account's password.
3. Enable write access to the OS partition:

   mount / -o remount,rw

4. Edit the file /usr/lib/python2.7/site-packages/unicorn/sharing/smb.py
   • Tip: vi is the only editor available. If you aren't familiar with it, copy the file into one of the folders in /shares/ and then edit it on another machine.
5. Search for unix extensions and change no to yes
6. Recreate the Python cache file:

   cd /usr/lib/python2.7/site-packages/unicorn/sharing/
   rm smb.pyc
   python
   import smb
   quit()
   

7. Return the root partition to read-only:

   mount / -o remount,ro

8. Reboot the NAS to pick up the change (restarting Samba isn't enough as the Python code we just modified needs to be restarted too.)

   reboot

After the reboot, /etc/samba/smb.conf should have been recreated automatically and should now contain the line unix extensions = yes.

You can now mount the share and create functioning symlinks successfully! With UNIX Extensions, the NAS UID/GIDs will now become visible, so you will need to override these to avoid permission errors on the local machine.

Here are the options I use to mount the shares from a Linux client in /etc/fstab:

//nas/share  /mnt/share  cifs  credentials=/etc/samba/private/nas.conf,noacl,nosetuids,uid=1000,gid=100,forceuid,forcegid,mapchars,file_mode=0644,dir_mode=0755,noperm 0 0

The options are:

noacl

The NAS doesn't use ACLs so this just cleans up the appearance of the files so they don't all look like they have empty ACLs attached.

nosetuids

Don't set the owner/group on newly created files, leave it at whatever the server wants. This is the behaviour when UNIX Extensions are disabled, so we have to specifically disable it now we've turned UNIX Extensions on. You don't need this of course if you *want* to be able to have different owners and groups on the files in the shares, but it's a moot point because you connect to the share as a normal user so don't have access to change file owners anyway.

uid=1000

gid=100

This is the owner and group that the files should appear to be owned by on the local machine. Since we are using noperm these are ignored, so they are only here for cosmetic reasons. If you weren't using noperm, you could set this up so that only this user can access the local mount.

forceuid

forcegid

Use the uid= and gid= options even when the server supports UNIX Extensions.

mapchars

Map characters that are illegal on Windows (:, ?, etc.) to and from Unicode chars that look similar. This will allow you to store files on the share with these characters in the name, rather than getting an error instead.

file_mode=0644

dir_mode=0755

Permissions to show all files and folders as having. Again these are ignored due to noperm. Without UNIX Extensions these are the modes (permissions) all files will get, however they are ignored when UNIX Extensions are enabled. This causes us problems, as typically the modes returned from the server are world-writable, so the local mount point can't be locked down anyway. Hopefully one day soon a mount option will be added for CIFS to respect these two options, even when UNIX Extensions are active.

noperm

Ignore all permissions client-side and let the server handle everything. I only use this on some shares I want to share with non-Linux machines, so that the permissions will always be set by the server for maximum compatibility.

The reason for most of these options is because I want to maximise interoperability between multiple machines accessing the same share. I don't want to have Windows machines unable to access files because I forgot to change the owner when I created the file under Linux.

If you will only be accessing a particular share from one machine, or all your Linux machines have the same UIDs and GIDs assigned, then you can consider leaving out most of these permission-disabling options to make the shares behave as closely as possible to how a local filesystem would act. However be aware that this alone won't be enough and you'll need to further modify the code that produces smb.conf. This is because the share is mounted as a non-root user on the server side, so that user will need to be mapped to root in order to allow a file's UID/GID to be changed. I'm not going to cover this because it gets a bit more complicated and it's not something I need to do - I am fine with anyone who has access to a particular share being able to access everything on it.

Background - Why use a NAS device at home?

In my endless quest to remove clutter from my computing area, I switched some time back to a rackmount PC. This worked very well to hide the PC away, however hiding the wiring as well meant that I needed five metre cables for most things.

Five metres is about the limit of many types of cables, with the most problematic being USB and DisplayPort. I found that passive 5m USB 2.0 cables would work for a few months then stop functioning, and active USB 2.0 extension cables would occasionally malfunction and the repeater end would become extremely hot. Fixing the problem required digging around in the back of the rack to unplug and reconnect the cable which was rather tedious. Active USB 3.0 cables were better, but again, some would work with some devices and some would not. Same story with DisplayPort, especially for 4K@60Hz.

Eventually I found a combination of cables that mostly work, most of the time, but the situation still isn't really ideal.

So to avoid this, I have decided to try out Intel NUC devices. With the latest models at last offering quad core CPUs (very useful for parallel code compilation), these are now as powerful as a real (non-gaming) PC, and they can be mounted on the back of a monitor allowing the use of very short cables. The only drawback is the limited potential disk space due to the small form factor, so by moving everything over to an Ethernet-connected NAS, I can enjoy as much disk space as I need without it taking up any space near my computing desk

Using SIMMs as SIPPs

Before the IBM AT and the 80286 were introduced, the RAM in most PC clones was comprised of a number of individual ICs plugged into sockets on the motherboard. Since the 8086 could only address up to 1MB of memory, this arrangement worked well.

However when the 80286 came onto the scene, it could make use of up to 16MB of memory. As memory was still very expensive, and motherboard manufacturers didn't want to populate their boards with thousands of IC sockets, a new standard was needed to allow memory to be expanded as needed by the end-user.

One of the first of these was the Single Inline Pin Package (SIPP), which had the same 2.54mm pin spacing as one half of an IC, allowing existing IC sockets to be used as receptacles for the new type of memory.

A 1MB SIPP module

The new SIPPs proved to be somewhat troublesome with their easily bent pins, and before long were replaced with SIMMs. SIMMs had no pins at all and used edge-connectors on the PCB instead, making them much more durable.

Since SIPPs were so short-lived, they are not readily available in the vintage PC marketplace. This is a problem for the retro PC enthusiast wanting to add additional memory to a motherboard with only SIPP sockets. When looking at my own "M209" 286 clone motherboard, the two spare SIPP sockets were crying out to be populated!

Two empty SIPP sockets, waiting to be used

Luckily, the two standards are electrically compatible, so all it takes to make use of SIMMs is some way of making the mechanical connection. There are a few options for this:

• Desolder the SIPP socket and replace it with a SIMM socket.
• Solder pins onto a SIMM, turning it into a SIPP.
• Use an adapter to convert the SIPP socket into a SIMM socket.

The first option involves removing the SIPP socket and replacing it with a SIMM socket. While this is a very good solution and only involves a little soldering, it is a rather permanent change and removes the novelty of having a somewhat rare motherboard that uses SIPPs. For me this was tempting, especially as my motherboard was designed to host either socket type - it already had SIMM mounting holes - but then there would have been one less unique thing about this motherboard so I decided against it.

The second option involves finding 30 bare IC pins, and soldering them onto a SIMM. This is not that unusual, as many later SIPPs were actually SIMMs with pins soldered on. Indeed the SIPPs that came with this motherboard are SIMMs with pins soldered on (see photo above of SIPP module.) However again, this solution is difficult to reverse.

The third option, making a mechanical adapter, sounds the most complex but turned out to be the simplest by far. Since SIPP sockets are simply IC sockets, anything that looks like it has IC pins on it will fit. A brand new SIMM socket has pins like this, making it possible to plug a SIMM socket directly into the SIPP socket, and have it function as an adapter. Being fully reversible, this is the option I went with.

I thought it would be difficult to track down a 30-pin SIMM socket, but to my surprise, they are stocked by RS Components and only cost AU$6. I ordered two, and a couple of days later they arrived.

A brand new SIMM socket

SIMM socket with protective foam removed, showing the SIPP-compatible pins

There is not a huge amount of grab in the socket as the pins aren't terribly long, but once everything is secure it does take a little force to remove again. The SIMM socket may come loose if SIMMs are removed, so probably best to remove the SIMM socket from the machine before replacing the SIMM memory stick itself.

SIPP sockets don't have any sort of mechanical keying, so make sure you insert the SIMM socket the right way! If you place a SIMM into the SIMM socket, one end of the SIMM has a groove cut into it. This groove is next to pin 1, and should line up with pin 1 of the SIPP socket, which should be labelled on the board (or possibly the opposite end is labelled with "30".)

Two SIMMs installed in SIPP sockets.

Otherwise, the solution works well, and my 286 correctly picks up the extra 2MB of memory added via the SIMM adapter.

4MB detected

At long last, I have maxed out the amount of memory on my 286 motherboard! (Although the 286 can address up to 16MB, this board only supports 4MB.)