3D Printed Raspberry Pi NAS With Dual Drive Bays

While it might not pack the computational punch you’d usually be looking for in a server platform, you can’t beat how cheap the Raspberry Pi is. As such, it’s at the heart of many a home LAN, serving up files as a network attached storage (NAS) device. But the biggest problem with using the Pi in a NAS is that it doesn’t have any onboard hard drive interface, forcing you to use USB. Not only is this much slower, but doesn’t leave you a lot of options for cleanly hooking up your drives.

This 3D printable NAS enclosure designed by [Paul-Louis Ageneau] helps address the issue by integrating two drive bays which can accommodate 2.25 inch laptop hard disk drives and their associated IB-AC6033-U3 USB adapters. The drives simply slide into the “rails” designed into the case without the need for additional hardware. There’s even space in the bottom of the case for a USB hub to connect the drives, and a fan on the top of the case to help keep the whole stack cool. It still isn’t perfect, but it’s compact and doesn’t look half bad.

The design is especially impressive as it doesn’t require any supports, an admirable goal to shoot for whenever designing for 3D printing. As an added bonus, the entire case is designed in OpenSCAD and licensed under the GPL v3; making modification easy if you want to tweak it for your specific purposes.

This certainly isn’t the strongest Raspberry Pi enclosure we’ve ever seen, that title would have to go to the ammo case that does double duty as a media streamer, but looks like it would make a great home for that new 3 B+ you’ve got on order.

37 thoughts on “3D Printed Raspberry Pi NAS With Dual Drive Bays

  1. “But the biggest problem with using the Pi in a NAS is that it doesn’t have any onboard hard drive interface, forcing you to use USB. Not only is this much slower, but doesn’t leave you a lot of options for cleanly hooking up your drives.”

    From Pogoplugs, to Routers people seem to be dealing pretty well with that limitation.

    1. “Banana Pi BPI-M1” just that board, all the later boards use USB 2.0 HS to SATA bridge chips (maximum throughput ~38MiB/sec), but the very first board had an actual SATA 2.0 connector and supported ~120MiB/sec but is limited to a maximum HDD size of 2TB. And the gigabit Ethernet will limit you to ~112MB/sec.

      1. I use that board for my home “server”. What I mean by server in quotes is that it is my NAS, webserver and always-on ssh server from which I can send a wakeup packet to my desktop when I want to access that remotely. It is also where I run any other random process that I want to keep going even when my desktop is off. (cron + fortune + cowsay + toilet = motd!)

        For these purposes it works great! Keep in mind though that I am really the webserver is just something I use for staging and doesn’t really have any public traffic. I have given accounts to my wife and a friend but they never use it so it really only ever has to serve me.

        Anyway… I don’t have any speed issues with it. I keep my operating system and most programs on my desktop’s local hard drive but I keep /home on the BPi. My ~/bin directory does contain a few programs that I keep there because they are custom builds, not managed by the package manager. Also I have a few windows programs that I run in ~/.wine .

        When I first set up the BPi-NAS it did take FOREVER (seemingly) to copy all my files over too it. I probably would have done better to just stick the drive in my desktop, copy the files and then move it to the BPi but… oh well.. The only speed issues I have noticed are a slight delay upon login when it is establishing it’s connection via NFS and when the hard drive is first spinning up from having been asleep (like I said, I’m the only user). Besides that I can’t tell that I’m not still running on a local drive!

        I must admit that I haven’t tried it but being USB2 I would think that a Raspberry Pi NAS would be a lot slower. I definitely recommend the BPi or any other board that includes a real SATA port that isn’t behind a <=USB2 bus.

        Oh.. and the directions say that you have to use a laptop drive or an SSD that doesn't require the 12V line… Forget that. Just ignore the on-board power connection and power your drive directly from a power supply that can handle it (w/ both 5 & 12V) . It will work fine. The BPi itself should probably also be powered from that same supply. Otherwise you will probably want to at least tie their grounds together.

    2. There is also the ODROID-HC2 which does use a USB 3.0 to SATA 3 bridge chip. So it is limited to a maximum transfer rate of ~240MiB/sec. But again the gigabit Ethernet will limit you to ~112MB/sec.

  2. I am thinking of building a baseboard with a Qseven or other pluggable System-on-Module; so we could just plug in a SOM and use it as a NAS (Plug-n-Play). After the availability of better performing hardware has been established, the user could just upgrade his module and use his existing NAS.

    I am thinking of opening a project here on hackaday and/or maybe crowdfund it. I am in talk with different hardware companies for that. Layouting the PCB and marketing would also be my job. However I’d be glad to have some help in marketing and case design.

    What do you guys think about it? Please let me know…

      1. The inability to use server-grade RAM would make it “unsafe”.

        But, as long as you’re taking good backups, that shouldn’t be a huge problem.

        And no one would use something like this in production, right?

        1. I smell paranoia here… Unless you want something like ZFS, ECC RAM is not a requirement for a NAS. Not everybody needs datacenter grade stuff.
          But yes, Pi isn’t really suitable for NAS use. Even the latest 3B+ only has a measly ~38 MB/s of bandwidth shared between LAN and 4 USB ports which is good enough for basic streaming but not for general purpose NAS. Not to mention the CPU bottleneck.

  3. I was like “600mA? Wait, what? I’m drawing more than that on my one system.” Then I noticed that article is from 2015, and is using a Raspberry Pi 2. Phew, close one.

    1. For these old boards you can double the current available for usb devices adding the option max_usb_current=1 to config.txt

      My external 2.5″ HD didn’t work with the RPiB+ due to low current until added that line. IIRC this enables the second mosfet passthru.

  4. I’ve been running a raspi NAS for a while, and it is slow for sure. When running a with raspi 3 I only got around 3MB/s average transfer speeds and now with 3 b+ around 6-7 MB/s transfer. There is a lot of speed lost somewhere as gigabit Ethernet should be 125 MB/s and USB 2.0 around 60 MB/s as far as I know. Only thing I can think of is the fact that the Ethernet and USB both go via the same chip so the speed is lost in the multiplexing?
    Anyway it works fine for safe storage and backup of files, and as a Plex server and torrent client, but the speed can be annoying when sending a lot of photos to it.

    1. The actual real-life bandwidth of USB2.0 is about 280Mbps or 35MB/s, not 60MB/s. Also, since the Ethernet is a USB-device, it literally cannot reach 125MB/s, it’s stuck at the same ~35MB/s. Then, think about when you’re e.g. transferring a file to it: the data goes in through Ethernet, to the USB-hub, the CPU, then back to the USB-hub, then to the drive, all the while the bandwidth is shared between the Ethernet and the drive — there’s your explanation for why it’s so slow.

      1. Yes, this is pretty much what I was thinking. I’ve run tests this morning and I actually get a faster 8-10MB/s transfer speed using the new 5GHz wifi abilities of the the pi 3 b+ than it’s nerfed gigabit.

    2. Gigabit after you factor in for data encapsulated into packets the maximum is ~112MiB/sec
      And USB 2.0 HS the maximum signaling rate is indeed 480 Mbit/sec (60MB/sec) but the actual data throughput rate is roughly 280-320Mbit/sec (33MiB/sec to 38MiB/sec) depending mostly on the actually chipset used, and then on the USB stack/driver in block transfer mode.

  5. This is something I’ve thought about doing for a while. I’ve struggled with the idea of how to keep the cables internal to the box. The Pi seems to have connectors coming off all sides of the board so it makes it difficult unless one wants to mount additional connectors in the case and build extender cables to tie these to the board.

    [Paul-Louis] didn’t tackle that particular issue, but he did follow through and build a beautiful, working solution which is far more useful than my hillside thinking. Congrats!

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.