NAS setup with an Argon EON
Looks like I am on a kind of ‘Argon run’ this quarter: since I upgraded the Argon One case to run off an M.2 drive, due to a stroke of lucky timing I managed to get an Argon Eon NAS case at a very fair price point - looking at the recent Shanghai supply situation, I consider myself lucky I got one at all!
I always fancied the idea of running a NAS in my home network, and regularly ogled the Synology products with my finger hovering over the buy-button. What held me back was the need-vs-pricepoint aspect, and the fact that I’d rather build a system from scratch. So that is where the Argon EON case comes in and pushes all the relevant switches - stylish, practical, put a Raspi and some disks in, voila!
My initial use cases are:
- running a timemachine capsule (now that I’m a Mac user!)
- doing my own backup of nextcloud-hosted data (in addition to the very professional service I’m privileged to be able to use)
The Argon Eon is all I expected it to be. It comes in a nice box with professional packaging, and is a robust, solid-feeling affair that is cleverly designed and a joy to look at and handle. The highlight: it includes a seriously fantastic screwdriver! The one thing that I wasn’t aware of pre-buy is that the case only has room for two 3.5” and two 2.5” hard disks - was expecting four 3.5”-sized bays. Not a realistic expectation considering the overall dimensions of the Eon, but I didn’t really think about that up front.
Installing the parts is what I can only describe as immensely satisfying. Sounds silly, but the scredriver that comes with the Eon is pure bliss. The box is very accessible when removing the two (magnet-held) covers, and while getting the raspi 4 board in place with the ports lined up properly takes a few mindful moments, putting everything together is obvious, easy and satisfying. I chose to run the raspberry operating system off a USB(3) drive located on the main-board, to have a clear separation between system and storage concerns.
My personal startup challenges
This is not something that will necessarily recur for other users - but I did have a really hard time getting the initial Ubuntu system to my desired state. My setup happened right around the time when Ubuntu 22.04 came out - but I initially attempted to install the previous LTS version and upgrade from there, no joy at all. The update process hung endlessly, doing (or not doing) unfathomable things with no feedback about what was going awry. I tried running this from the SD card, the USB drive, no difference. Then after some googling I managed to find the brand-new raspberry image of 22.04 server, which worked from the get-go - so a lot of hand-wringing about nothing. In retrospect I am certain that the Raspberry Ubuntu Server image only became available after I had spent a day trying to upgrade the older version, but that might be just me justifying my excitement getting this Raspberry board set up ;-)
The final snap was when I had the base system up running beautifully off it’s USB drive, had that cloned to a SD card for good measure, and then went and installed the hard disk drives. For reasons I still don’t understand, that completely removed any usb disk devices from the Ubuntu system. The new harddisks didn’t show up, and the USB drive supposed to be the boot device also was gone (with the system happily booting off the SD card I cloned to earlier). Googling et al didn’t help me figure out what went wrong or how to fix this, so I went and reinstalled everything, again. For some reason this time all went well up to and including installation of the spinning disks, at which point I was finally able to go ahead with configuring them into a raid 1 array - see next section.
What to do with the disk-bay size options of the Argon Eon? Originally I was thinking along a raid level 5 setup using three disks, with an option to add a fourth later. Not primarily because I need the space, but because raid 5 always felt like the best compromise between disk space overhead and redundancy. After doing some shopping-research around NAS disk drives and seeing that there’s some useful options for 3.5”, but no dedicated ones for 2.5”, I decided to go with a raid level 1 setup with two 3.5” NAS-optimized hard disk drives. In my case I optimized disk selection for energy consumption and price point, settling on two 4TB drives for my initial setup. I can always add one or two 2.5” drives to that cluster and promote it to raid 5 - there are no dedicated NAS options in that size category, but should I need more disk space there at least are ample options for 2.5” spinning metal in the 4TB class.
Once these decisions were made, the drives ordered and delivered, the actual raid setup was anticlimatic. There are myriad guides out there, one of the ones I was looking at is this one. Having a raid 1 partition running, I’m now looing at an Ubuntu 22.04 LTS installation with some personalization options like oh-my-zsh, the raid cluster mounted into the file system, and the usual docker and docker-compose tools that I want for all the productive workloads.
Timemachine capsule setup
Running a timemachine backup server for MacOS is a very straighforward thing - there exist a number of docker hub images for the task. As always the selection process involves availability of reasonable documentation (indicating aspiration), recent updates (inidicating commitment) and of course availability for the Raspberry target platform. In my case I went with mbentley’s timemachine image which ticks all these boxes. Getting this running is trivial, based off the following docker-compose file:
version: "3.7" services: timemachine: network_mode: "host" environment: - CUSTOM_SMB_CONF=false - CUSTOM_USER=false - DEBUG_LEVEL=1 - EXTERNAL_CONF= - HIDE_SHARES=no - MIMIC_MODEL=TimeCapsule8,119 - TM_USERNAME=timemachine - TM_GROUPNAME=timemachine - TM_UID=1111 - TM_GID=1111 - PASSWORD=timemachine - SET_PERMISSIONS=false - SHARE_NAME=TimeMachine - SMB_INHERIT_PERMISSIONS=no - SMB_NFS_ACES=yes - SMB_METADATA=stream - SMB_PORT=445 - SMB_VFS_OBJECTS=acl_xattr fruit streams_xattr - VOLUME_SIZE_LIMIT=0 - WORKGROUP=WORKGROUP - ADVERTISED_HOSTNAME=nas restart: unless-stopped volumes: - /mnt/raid1/timemachine:/opt/timemachine - timemachine-var-lib-samba:/var/lib/samba - timemachine-var-cache-samba:/var/cache/samba - timemachine-run-samba:/run/samba ulimits: nofile: soft: 65536 hard: 65536 container_name: timemachine image: mbentley/timemachine:smb volumes: timemachine-var-lib-samba: timemachine-var-cache-samba: timemachine-run-samba:
Note that my setup includes a user and group on the host machine matching this docker-compose definition, named “timemachine” with uid/guid 1111. Also, evidently, my raid disk is located at
/mnt/raid1/, and the
timemachine/ subdirectory is used for storing mbentley/timemachine backups.
One more thing
First step: done
This is sufficient to have a
timemachine backup server appear in my Mac timemachine preferences dialog and the Mac happily use it for timemachine backups.
I will look into my backup scenario for nextcloud data in a separate article.
- Argon40 have again put together something cool with the Argon Eon NAS case
- Hosting your own timemachine server is trivial, thanks to the efforts of others