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