Raspberry Pi as NAS

My old Synology USBStation 2 just died. Fortunately all the data on the two drives appear to be intact (I plugged them into the Linux box to check).

I’ve just ordered a Raspberry Pi 3 B+ kit with the intention of turning it into a NAS at least as good as the USBStation 2.

Does anybody have recent experience of doing the same?

I was hoping to find a more powerful PSU, since both drives are spinning rust (2.5" portables), but the most powerful one I found was 3 amps, so that’s what is on its way to me. The USBStation 2 has been on a 2.5 amp PSU, which does appear to be enough and still holding up, but I can’t easily measure its consumption and I don’t know what the 3 B+ consumes, so I can’t do an easy comparison.

I’ve always been happy enough with the speed of the USBStation 2, although any improvement will be mildly welcome. I don’t want the expense of running anything with a bigger CPU 24/365 and I certainly don’t want the noise of a fan. The USBStation 2 spun the drives down after a few minutes (or maybe they spin themselves down, I don’t know), so it has been silent most of the time.

My search on the web yesterday indicated that there are three NAS distros, although one didn’t get much of a recommendation. I assume they must be more or less standard Linux distros with configuration added, and maybe a GUI – I would want it to run headless and be administered remotely if possible.

Whilst I appreciate the low price of Pi, for NAS use I wouldn’t want to use something that uses USB for ethernet and disc connectivity. It strikes me that is a significant bottleneck (remember, it’s all USB 2). Not to mention the attractiveness of sata for a NAS. I believe there are a few alternative single board computers that have dedicated ethernet ports now, which might be better choices, although price may be against them.

To answer part of your question, Pi 3 B+ is 2.5A with things on USB, and any external hard drives will likely be fairly demanding on that. 3A should suffice, but you’ll be close, depending on the USB drives (since most portable drives assume USB 3 power supply levels, or use a Y-cable). For NAS use, I’d consider using separately powered discs.

Not really related, but a fun product in this category are various eSATA RAID enclosures. These can be hooked up to SATA-based systems to give multi-disk raid setups, ideal for NAS. There are a selection on Amazon, for example.

I wouldn’t want to use something that uses USB for ethernet and disc connectivity.

To further add to what Andrew said, I would like to point out that not only is the Pi using USB for Ethernet and disc, it is actually using the same USB port. The BCM-whatever chip has one single USB port, which is connected to a little chip that is both an Ethernet interface and a USB hub. So your four ports and network connectivity are all being routed through the same single USB port.

This may not matter. USB 2 and a processor clocking around a gigahertz ought to offer more than enough bandwidth to stream a movie, even with the bottleneck. However for more intense uses such as backing up data, you may feel it lagging.

That said, making do with a small Pi is cheap and cheerful. A proper NAS will function better, but at a cost. It’s like asking whether you’re happy with a Citroën or a Porsche… Both have attributes, both can do the same task albeit in quite a different way.

Further useful bit of knowledge that I’ve just picked up reading around things, USB2 is only half duplex, so you can’t be reading and writing at the same time. Again, this may not matter, but it’s another reason why you wouldn’t really want it all on one USB as Rick says. The Pi will effectively be reading from the drive, but writing to the network port. At half duplex, it can’t be doing both.

Although this may vary with OS, it also explains why writing can be so slow to USB-connected devices – there’s often a read/verify after a write, which effectively halves write performance.

Obviously all this applies to all USB2 controllers, but can be mitigated by either having things on multiple controllers (I guess) or having ethernet on a separate (full duplex, non-USB) controller. USB3, by contrast, is full duplex.

While a RPi 3B+ is certainly not ideal for building a NAS (as other have said, you’d want multiple S-ATA ports as well as true Gigabit ethernet and everything attached to a nice fast internal bus – and if you’ve gone that far, why not add a beefy CPU with a lot of RAM to be able to use ZFS as the filing system?), if you want to access it mainly from RISC OS, it should be sufficient. RISC OS is seldomly able to outpace a 100 MBit/s network connection.

There’s no particular reason any of you should be familiar with the USBStation, but the small clue is in the name. It turns USB drives into NAS. I already have the drives. Although no doubt they are internally SATA, I would have to break into the cases to get at that interface. So it has to be another USB NAS adapter of some kind.

Dave, yes, that’s why I didn’t go on at length about SATA, because it wasn’t directly related to what you wanted. I was trying to explain why pure-USB2 is not ideal, even for what you’re doing. The USB-station wouldn’t have used half-duplex USB-ethernet. I did a google search last night. I found the Orange Pi 3 (price competitive with Pi3) which might be a better choice. USB3 internally, and gigabit ethernet (not sure if it is native or USB). With USB3 being full duplex it’d probably be a better fit for what you’re doing.

Note that I (purposefully) haven’t mentioned any R-Comp products thus far. However i.MX6’s ~500 Mbit throughput on its (hardware) ethernet makes it less than ideal for a “proper” NAS appliance, but might well suffice for your USB devices (and has 2x USB controllers). A mini.m with USB and eSATA, might give some fun options. But, for that price, you could get a proper NAS enclosure, many of which can share USB-connected drives.

But, I think, this isn’t why you posted in the first place. I guess I’m just trying to explain/justify why it can be worth discussing things like this with folks like me.

So, rather than me appearing like a bit of an ass, here’s what you were really looking for, I think – using a Pi as a NAS:

https://thepi.io/how-to-use-your-raspberry-pi-as-a-nas-box/

and

https://sourceforge.net/projects/openmediavault/files/Raspberry%20Pi%20images/

I have an Orange Pi 3. It’s a beast but the support just isn’t there yet. The Armbian people are hard at work trying to get features working. Who knows if anyone will bother making a modified driver to support the quirky eMMC slot. Worth mentioning is the USB3.0 is a single SoC port with hub. But as said it’s not an RPi.

E: pretty sure the gbit ethernet is internal.

Well, the RasPi 3 B+ arrived today, and I’ve got Open Media Vault running on it and shared one of the USB drives that were on the USBStation 2. The Linux box can connect to it, but LanMan98 can’t. This shows that I’ve got the share set up correctly, but there’s some incompatibility with LanMan98.

I’ve found out about the versions of SMB that OMV supports, but downgrading the client min protocol to LANMAN1 or LANMAN2 doesn’t help. I still get “Access denied” from LanMan98.

Got to go to bed now – end of experiments for today. More head-banging tomorrow, no doubt.

I got it working properly. The secret sauce to make it work with LanMan(98) is to add “ntlm allow = yes” to the Extra options for CIFS/SMB. (I just wish it hadn’t been such a struggle to find.)

The result operates at pretty much the same speed as the USBStation2 that it replaces. So I’m happy.

Interestingly, I put both drives on a powered hub (D-Link 7 port with a 3 amp PSU), but the RasPi still complains of undervoltage detected when it starts to do anything. That’s despite it having its own 3 amp PSU. The D-Link hub doesn’t appear to back-feed power, so I don’t think it’s caused by demand from the drives.

Anyway, the original question was whether anyone had experience of using a Raspberry Pi 3B+ as a NAS. No-one seems to have answered yes, so I assume I must be the first in this forum to do so. (In view of a recent comment in another thread, I should state that I’m not trying to score points off anyone, so please don’t read any of this as if I am.)

It works as a NAS. The performance won’t set the world on fire, but it’s OK for me. I don’t have any uses that consume great bandwidth.

One nice bonus is that it shares as NFS as well as CIFS/SMB.

It appears to support SMBv3 too, so, if LanMan ever catches up with the rest of the world…

So can you connect to NFS shares from RISC OS using SunFish?

I have SunFish working nicely to access my Linux laptop from RISC OS, but for some reason I cannot get SunFish working to access a Raspberry Pi running Raspbian over NFS. The Linux laptop can access the shares on the Raspbian machine, so I am not sure what is wrong.

I did have MoonFish working well so that I could connect to the RISC OS machines from the Linux laptop, but annoyingly a few months ago that stopped working and I have no idea what I changed. I didn’t use it in that direction very often, so when it stopped working I could not pinpoint what change had caused it.

So can you connect to NFS shares from RISC OS using SunFish?

Yes, it Just Works™.

Carefully reading your observations, the only thing I can imagine is something to do with the NFS versions. I know that ticking the NFSv4 option in Moonfish causes some problem, although I can’t remember exactly what and I don’t want to break things now!

When you say “cannot get SunFish working”, what exactly are the symptoms of failure?

Thank you for pointing me at the NFSv4 option in Moonfish. At some stage I must have turned it on, hoping it would help with one of these problems. Turning it off, I now find that the Linux machines can mount the RISC OS filesystems successfully again! This is a great improvement.

I’m sure I used to have a problem, from time to time, of writing files to the RISC OS machines from Linux. I just tried a simple example and it worked, though. Now that the connection is functioning again I will keep an eye on this.

I still have a problem connecting to the Raspbian machine using Sunfish. I’ll do some more investigation.

The Moonfish manual mentions that there are fewer NFSv4 clients than NFSv3 clients, so at the time Alex Waugh wrote it, perhaps he did not have many clients to test with. If so, it’s possible there are some problems with the Moonfish implementation that need ironing out. This could also explain my difficulties with Raspbian if it has dropped support for earlier NFS versions. I know I had to do something special to get the portmapper running.

For the record, my settings currently are:

Moonfish:
Transport protocols: UDP, TCP
Convert NFSv2 and NFSv3 filenames: No conversion
NFS protocols: Portmapper, NFSv2/Mount v1, NFSv3/Mount v3 but not NFSv4
Autoload module at boot
Ignore extensions of resource fork unticked.

I have the Iyonix hard disc exported as /iyonix and the options for that export are:
umask blank
unumask 600
UID and GID blank
Fake directory timestamps ticked
UDP transfer size 4096
Read only unticked
Treat image filing systems as directories unticked
Default filetype FFF
Add ,xyz extensions only when needed.

I’m not sure what all of those options mean. That is, I’ve read about them in the Moonfish manual but I wouldn’t like to say that I have carefully considered many of the settings.

Regarding Sunfish, I currently have a configuration file (filetype Sunfish/1b6) set up as follows:

Protocol: NFS2
Server: 192.168.1.2
Export: /home/matthew
UID: 1004
GID: 100

Double-clicking on it gives the error:
Error when reading ADFS::HardDisc4.$.Network.NFS-server-1-matthew – RPC failed (Remote program mismatch

I tried changing Protocol to NFS4 but that gave
Error when reading ADFS::RamDisc0.$.NFS-server-1-matthew – Unknown protocol ‘NFS4’

But changing the protocol to NFS3 worked! This is excellent. I think I now have everything working in all the directions I need.

The only other puzzle I have is why Sunfish is so much slower than FTP. I have used Hard Disc Companion for many years to do backups. Originally, way back, this was to an external SCSI drive attached to a podule on the RISC PC, but more recently I have used a NAS. I have found that the quickest method of doing the backup is to get the Iyonix to write the backup files to its own hard disc first, and then copy them all using FTPc to the Linux NAS. I tried using Sunfish and pointing Hard Disc Companion direct at the NAS like that, but it was quite a lot slower.

I know nothing about the underlying FTP or NFS protocols, so I do not know if NFS is intrinsicly less efficient or whether the difference can only be explained by the implementation.

In theory, NFS should be about as fast as FTP – both protocols are optimized for minimum overhead. NFS has its own flow control, which should make it slightly slower, but makes it able to work over UDP, which should make it slightly faster.

However, the RISC OS IP stack and the network drivers are not exactly known for high throughput, which can lead to problems depending on the relative speed of clients and the flow control used and maybe even the network switch in between the devices. So as a first trial, I would try to force Sunfish/Moonfish on either UDP or TCP and measure the performance you get.

I use Sunfish to mount shares on a Synology NAS and use Steve Revill’s 7backup on a nightly basis to back up the ARMX6 on a GB network – the whole process takes roughly 2.5-3mins with 7GB of data, only copying changes. The bulk of the changes are in !NewsDir – currently 840MB.

Sorry to ask, but, isn’t OmniClient supposed to support NFS?
(just need to activate it at launch).

Sorry to ask, but, isn’t OmniClient supposed to support NFS?

OmniClient does – in itself – not support any networking filing system at all, so the question is kind of non-sensical, but I understand what you mean :-)

There are various OmniClient plugins (don’t know if “plugin” is the official wording – “OmniClient clients” sounds strange!) around like LanManFS, LanMan98, Access and indeed NFS of ancient Acorn heritage which was resurrected according to CVS logs just recently. Not sure if it already made it into any recent disc image.

I don’t think Sunfish can act as a OmniClient plugin (like e.g. LanMan98 can do – not sure if ImageNFS, the long-forgotten WSS NFS counterpart to LanMan98, could do that). Would make up for a nice project to extend Sunfish to be able to act as an OmniClient plugin – ISTR the Acorn NFS client only suports NFSv2.

but I understand what you mean :-)

:)

Not sure if it already made it into any recent disc image.

I’m pretty sure it is. But you have to activate it on the !Run file.
(or something similar).

NFS is included with OS 5.24 and later. I use it regularly, so can confirm that it works (at least for my use case).

Are there any instructions for setting it up? Sunfish is working for me, so I’ve never looked at OmniClient or it’s NFS ‘plugin’. I’ve never got on with LanMan/Samba shares from RISC OS so I stuck with NFS and it mostly ‘just works™’. Which would be the best one to go with in the longer term? I assume OmniClient is more likely to be maintained than Sunfish.