Hacking An Extra SATA Port Into A Thin Client

Thin clients were once thought by some to be the future of computing. These relatively low-power machines would rely on large server farms to handle the bulk of their processing and storage, serving only as a convenient local way for users to get access to the network. They never quite caught on, but [Jan Weber] found an old example and set about repurposing it as a NAS.

The Fujitsu Futro S900 was built up to 2013, and only had one SATA port from the factory. [Jan] wanted to add another as this would make the device more useful as a network attached storage server.

The motherboard design was intended primarily for industrial control or digital signage applications, and thus has plenty of interfaces onboard. [Jan]’s first target was some unpopulated footprints for SATA ports onboard, but after soldering on a connector, it was found that the BIOS wouldn’t recognise the extra ports anyway.

However, after reflashing the BIOS with one from an alternate model, the port worked! The system also seemed to then imagine it was connected to many additional LAN interfaces, but other than that glitch, the hack is functional. Now, with a pair of 2 TB SSDs inside, the S900 is a great low-power NAS device that can store [Jan]’s files.

It’s a tidy hack, and one that will likely appeal to those who prefer to run their own hardware rather than relying on the cloud. If you’re working on your own innovative NAS project, be sure to let us know!

23 thoughts on “Hacking An Extra SATA Port Into A Thin Client

  1. The MAC and UUID got lost because they’re kept in a config block on the same flash but its now been overwritten by the empty config in the firmware image file. The manufacturer supplied updater knows not to erase/overwrite that region but flashrom defaults to everything. The OEM tools from AMI to program the UUID and other settings have been leaked so you can reprogram it from DOS + Windows if it really bugs you.

    1. Similar thing happened to me when I was BIOS hacking my gaming rig, I had to use a CH314a and clip to do a raw flash to recover from brick, and it resulted in my onboard Ethernet MAC being all 88’s, haha! Still haven’t bothered to fix it, no idea how…

  2. I played with a few repurposed thin client laptops. Rescued from a dental office, the were kitted with a 4 gig SATA chip, and a splendid Core 2 Duo CPU running at 2.5 Ghz. Lucky me, the 4 gig chip had a standard SATA connection. I slipped in a 250 SSD, and boom, windows installed perfectly. Extra ram and away we go..

  3. > Thin clients were once thought by some to be the future of computing.

    They sort of were, just not as implemented at first.

    The first ones were dumb terminals printing mechanically onto paper from Baudot code… often an electromagnet and a motor are the only “electric” components.

    Eventually a small CRT display controller was integrated and so instead of printing out on paper, it drew it up on a long-sustain phosphor screen.

    Various protocols were developed for these thin clients, but the DEC VT-100 and descendants being the most dominant.

    X protocol was released, and so “graphical” thin clients targeting that came out.

    VNC was developed, and some thin clients started supporting that.

    Microsoft jumped on the band wagon with Windows NT Terminal Server and Remote Desktop Protocol.

    There’s also Spice protocol, a competitor to RDP/VNC.

    Today, we use HTML, CSS and some JavaScript to implement a “thin” client.

    So it kinda was “the future”, but it’s also our past too. A device with “lesser” compute resources, being used as a user interface to another “greater” computer system.

    1. I would argue, with how much overhead a browser requires, and with how much ram and compute modern websites/webapps devour, that html/css/js isn’t a thin client, because it requires a thick enough client for reasonable performance, due to clientside designs with js. I would more liken it to the vision for java, a virtual machine or common runtime environment that is a sort of OS on top of an OS.

      1. While there is a great deal of bloat on the modern web all these dynamic pages require huge resources at the other end to effectively ‘compile’ the website for each client too, so you could call the clients thin… Plus many of them are portals to that machines processing too, so I think its fair to say you are both kind of correct…

      2. Thin client isn’t so much about where most of the processing is, but where the data is. If the device in front of you is just displaying data assembled for presentation elsewhere, then you have a thin client.

        1. i totally agree that a browser is akin to a thin client but i think this attempt to put a firm semantic basis on it shows the problem with that statement (which i still believe in even so). a device that interacts with data stored on a server is called a ‘client’, its thinness is actually irrelevant to where the data is.

          i think the ‘thin client’ idea is basically just a euphemism for ‘just client’. in that brief era between teletypes and web browsers, PCs were based around this crazy idea that all processing would be done locally. it was common for the only access to remote data to be through physical media. and in that context, ‘thin client’ was introduced as a concept just to get people to imagine their PC being a client to access remote data with no real local data processing ability. and i think that model has more or less won the day even as the dimensions of a ‘thin client’ have changed to seem thicker.

    2. but it’s also our past too. A device with “lesser” compute resources, being used as a user interface to another “greater” computer system.

      So, a chromebook/box… The “lesser” (ChromeOS Machine) connected to another “greater” (Cloud Server) :P

  4. This reminds pup of the time back in 2013 when pup got a aspire one netbook with xp installed. It used an zip flash media as it’s hard drive but was very slow and over time would just crash and would have to keep reinstalling windows. It had a spot for an onboard sata drive but was never populated. After adding a laptop SATA port to it has well as bridging the power traces to it it worked and even showed up in the bios. Afterwords ran find and eve faster and stable. Sadly though had to sell it to help pay bills >< but was a very cool small netbook ^^

  5. At first I wasn’t sure where there hack in this was – to add a second SSD into my S900, all it took was soldering up a SATA-power cable to match the header on the motherboard. But having to populate the headers first and then getting different firmware on the board does make it indeed more impressive.
    Sidenote on NAS usage: I measured power consumption of my S900 (with SSD added) at about 12-13 W idle. My banana pi in contrast only needs roughly 2-3 W. So depending on expected runtime and your countries energy prices, the old Futro may not be the most economical solution. Despite the fact they can be really cheap.
    An advantage I see is that they come with case and power supply, a factor often overlooked when comparing ‘cheap’ SBCs. Also, this specific model has 2 real RS232 ports, 6 USB ports, front and back audio (mic and speaker each), full size DVI and DP, LAN and even two PS/2 for keyboard and mouse.

  6. I use this kind of thin client at home for me and the kids with dedian… as a fat client king of sobriety…
    It is hard to use only the existing 4GB sdd… but a full sdd can be added.

  7. I’m running an HP t5740 with PCIe expansion as an Open Media Vault server. The expansion (when bought new) comes with both a PCI and a PCIe riser. The PCIe one is x16 size but only connected as x4. I put an eSATA card in and connected a 500 gig eSATA drive.

    A caveat with this series of HP thin clients is “half slim” SSDs won’t fit. They’re too wide. The SATA+power connector on the board sits at a right angle to the riser slot, nearly bang up against it. An HP SSD made for these could be used, but like the Firmware modules for the really old JetDirect print servers they’re impossible to find.

    So the fix is to seek out an SSD with a PCB no wider than the SATA+power connector and a right angle adapter. Left or Right will work though there’s more room to work with having it towards the CPU heat sink. The mounting ears have to be cut off the ends of the adapter to clear the riser slot and a large capacitor.

    Or you could find a big enough 44 pin IDE Disk On Module and use that. Or use both, without the expansion chassis, if you can cram a 2.5″ SATA SSD in there somewhere for storage and run OMV or whatever off the IDE DOM.

    These are 32bits so installing Open Media Vault is an online install after booting with a bare bones Debian USB stick.

    It works just fine for simply DLNA serving of files to clients (like Smart TVs, phones, and tablets) that have their own ability to play the files. I don’t know how many users it could handle simultaneously, but for me it easily handles two at a time. I don’t use any of the many other features of OMV5.

    What I want to do is get an x4 PCIe NVME adapter to install a PCIe NVME SSD internally. Then it can be a “take anywhere” media server, very physically compact, using just a few watts of power, though changing the IP address can be a bit of a pain if it’s set to be fixed instead of using DHCP. Another idea I’ve though about is getting a second expansion chassis and modifying it to mount on top of the first one, then carving away whatever would be in the way of a high capacity 3.5″ SATA drive. Put a SATA card in the PCIe slot and find a really short cable. Would likely need an external power brick for a 3.5″.

    A second internal SATA+power port can be added simply by soldering the connector to the pads by the 44 pin IDE connector.

  8. I’ve gotten to the point in my life if I need a dedicated system I will hit up ebay and buy a thin client. In the adventures of doing that I use DELL brand thin clients since DELL doesn’t lock up the firmware as tight as other manufacturers. The last system I bought however was an HP and it annoyed me but I wnated to give HP a try. A nice board I really like (pre covid) was the PC Engines APU2 boards but it’s not really a Thin Client but more of an industrial use board but is used in the pFsense community. Not sure on their supply now.

  9. Ha ha, the irony.
    The main benefit of thin clients was not that they offloaded processing to the network, but that they offloaded storage, and thus, configuration, management, etc, to the network. The OS, and it’s configuration could be central, and therefore more secure, backed up, easy to change, manage etc, and the same with the user’s files.
    To use a thin client as a NAS is quite a turnaround.

  10. Nope, there’s nothing you can do with a thin client, and nobody should go buy any pushing up the price of the ones I like. Err…

    Some make a handy server when given extra ram and an 860evo m2 ssd… Eases the load on the Raspberry Pi 3 that was previously doing all serving duties in the home.

  11. i have always been an advocate of ‘fast enough’ as the metric to aim for but nonetheless every time i have thrown old / cheap hardware at the NAS problem i have been astonished at the low performance of their I/O interfaces. maybe i have been unlucky, or things have improved since i tried last. i mean, gige and SATA 6Gb/s seems like they’ve been standard for such a long time.

    of course my PC’s local drives are SMR now and blocks on all I/O for tens of seconds at a time if you ever write more than a couple GB in a burst. and almost all of my devices will fail over to 100Mbits ethernet after a few months of uptime, and i never seem to notice. i guess it takes more giving a hoot than i’ve got in me to get even a significant fraction of modern performance.

  12. Thin Clients are used for ALL the employee-facing computers at the large US retailer I work at. They’re mostly some low-powered Dell boxes running an Atom, but all they have to do is host a web browser and MS Office apps. They may not be the “future” of computing but they’re an extremely economical option for large companies.

    1. Some would argue that thin clients are “successful” already, what with Chromebooks and the recently announced Chrome OS Flex. These “cloud focused” clients are essentially the same thing, really.

  13. Very cool. I’ve been meaning to look into a dedicated device for my local backups, and I’ve looked into thin clients but was always turned off by (usually) a single SATA port. Though I’m wondering if this will be better in long term, my current working idea is to use a Pi 4 Computer module with a PCIe SAS card…. but then you’ve got a case and PSU to worry about powering it all. Still, that seems to be the best DIY approach to having 4 or more drives in RAID.

  14. I love the idea of a thin client. I had one in my garage workshop for quite a while with my much more powerful desktop that lives upstairs as the server. X made remote display easy. I never could get remote sound working though. I also meant to get remote USB connections working so that I could do things like program an Arduino through it but never really got around to trying.

    Pulse Audio sounded like it might make getting the remote audio working easier. But like other Poettering software it claims to do everything but only using it exactly how RedHat expects you to does it actually function. I could get audio working but only with lots of manual commands that needed to be re-typed upon every sign in. And even then the lag was horrible.

    Now with Wayland and remote support moved to the developers of every individual compositor It seems unlikely this will ever work right except maybe for people that use one of the big DE’s like Gnome, KDE or whatever Ubuntu is pushing today. Or someone with the time and ability to code their own compositor. So sad!

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.