Setting Up a Home NAS for MiSTer Think About Using RetroNAS

[redsteakraw]

https://odysee.com/@retrorgb:c/introducing-retronas:d

RetroNas is a home server software that has support for all your retro computers, MiSTer and softModded consoles to serve up your games and media and interact with older hardware. This also supports symlinks and has native MiSTer support(see video above for information how). You could also use this to interact with some of the older computer cores. Project is easily configurable and is in active development. So check it out when looking to set up a gaming NAS.

[redsteakraw]

Here is the current project:
https://github.com/danmons/retronas

and here is what is planned:
https://github.com/danmons/retronas/blob/main/IDEAS.md

Looking at all that shows that there is diffidently a lot of interesting things ahead. Having a sync with GoG and being able to launch the games from your network drive would be awesome as well as saving money on SD cards by just getting a large drive I can host my GoG games, Roms, Images and more (Hopefully also my Steam library) and be set on my home network. Possibly even on the go if installed onto a Raspberry Pi 4 with a Sata hard drive enclosure.

[elvis]

Hi there,

I'm the RetroNAS author. Happy to answer any questions about it here.

Before the "isn't it just another NAS?" questions start - RetroNAS does lots of different things, however if all you want is a place to store MiSTer ROMs, you probably don't need most of what it has to offer.

MiSTer takes away a lot of the troublesome aspects of retro computing. Want a bigger hard disk? Make a bigger hard disk image (and/or multiple hard disk images). Want to mount fast network storage? Do it below the emulated system at MiSTer's Linux layer, and forget about networking hassles.

If you're using something like a real retro DOS computer, EtherDFS to RetroNAS is great (non-IP, lightweight layer 2 network sharing protocol that you won't find on any other NAS). If you're using ao486 on MiSTer, don't even bother. Use misterfs.exe to bring up your CIFS share from any old NAS, and you're good to go.

Where RetroNAS is of benefit is if you ALSO have a tonne of other systems. SMB1 is there for OpenPS2Loader (which many NAS devices still support, although it is slowly being deprecated by some vendors). But in addition there's ps3netsrv for CFW PS3 network game loading, AppleTalk (non-TCP version via Netatalk2, which is working all the way back to GSOS/System6 without the need for TCP/IP) and TNFS (lightweight UDP sharing for Atari 8-bit and ZX Spectrum). FSP is in development (GameCube ISO network loading via Swiss), and DECnet and IPX are planned (for old DOS/Windows/UNIX systems). But again, if you are emulating these via MiSTer, you probably don't need any of that, and a bog standard SMB2+ NAS is all you need.

RetroNAS does have a symlink feature where it links multiple systems into a generic ROM dir format to make sharing of ROMs across mismatching emulation systems easier (saving space). I just added Smokemonster SMDB support this weekend as well so you can import random collections of ROMs into sorted and renamed collections. But again, you can do this yourself - the SMDB tools use Python and can run on Windows just fine, and the symlinks anyone can create for themselves on a commercial NAS (there's a lot of them, but it's not rocket surgery).

RetroNAS can also offer you transparently compressed file systems and block-by-block deduplication below your ISO and VHD images for considerable space saving, but again, so can many other NAS devices.

I don't profess RetroNAS to be better than commercial NAS devices. It does a lot of quirky things you can't do on most NAS devices, but these things are only really of value to owners of original hardware, museums, preservationists, etc. If you're experiencing all of these systems by either MiSTer FPGA or software emulation only, the extra features probably aren't worth your time as you can do other things to solve the problem of accessing files and data.

Apologies for the wall of text, just fending off some of the questions/comments already discussed on various social media. If you're still interested in RetroNAS, I'm happy to answer questions. If it's of no use to you because you already have a functioning NAS solution, that's perfectly fine too.

Alternatively, if you don't have a NAS, but do have a spare RPi, junker computer, or know how to install a basic VM, RetroNAS might still be useful to you if you don't want to share directly off your desktop/laptop device.

[Brendle]

Hi. The install guides I've found are all for installing RetroNAS to a RasperryPi, I'd like to install it to an old PC. It has to use Linux, right? Which lightweight Linux does it work with? My PC is pretty old and underpowered. I'm going to try AntiX Linux first, Debian 11 Bullseye looks a bit too beefy for my old computer. I'm hoping that after I get that done, the rest of the installation process is the same as it is with a Pi.

[Dougdoesnt]

This past week I setup a pi4 w/ a USB3 HDD as a retroNAS. I followed Bob's videos to setup the retroNAS. I loaded it up with everything I wanted for MiSTer including the ao486 top 300 pack. I did a fresh Mr Fusion install on a 64GB SD, then I grabbed the mount_cifs.sh and followed Dan's video to figure that part out. Everything is auto mount as if it was the local directory and it works great. Update_all.sh and the top 300 update script both found all their directories on the retroNAS no problem. Very smooth. The only thing that surprised me was that with the cifs mounted (all the time in my case), if I stfp into the mister's local IP I can delete the files out of the /media/fat/games/ and actually be deleting the off the retroNAS. It REALLY treats it like the local folder LOL

Excellent combination of software! Beautiful so smooth!

[elvis]

Hi. The install guides I've found are all for installing RetroNAS to a RasperryPi, I'd like to install it to an old PC. It has to use Linux, right? Which lightweight Linux does it work with? My PC is pretty old and underpowered. I'm going to try AntiX Linux first, Debian 11 Bullseye looks a bit too beefy for my old computer. I'm hoping that after I get that done, the rest of the installation process is the same as it is with a Pi.

Currently RetroNAS requires Debian 11. I'd like to change that to be more distro agnostic long term, but that's where we're at currently.

Debian 11 will run on very low end hardware. I've got it personally loaded up on a 32bit Pentium M 1.5GHz, single core, 768MB RAM laptop and it runs fine on that. I run the LXQt desktop on that laptop which is very lightweight. You can bypass a GUI all together and use next to no resources.

I've got a short video on how to get Debian 11 on a VM. The process would be identical on an old laptop or desktop class system. Bob is aiming to have one out soon about how to repurpose an old laptop too (he's waiting for RetroNAS's newest GUI improvements to come through, but you can try now if you want).

https://youtu.be/i5VgHflLHNE'

Debian's official minimum requirements are a single core 1GHz CPU with 512MB RAM. I'd probably recommend at least 1GB though if you're going to load it up with services. SMB alone won't require a huge deal, but if you're going to add a few extra services or use our new GUI management, it'll help.

This past week I setup a pi4 w/ a USB3 HDD as a retroNAS. I followed Bob's videos to setup the retroNAS. I loaded it up with everything I wanted for MiSTer including the ao486 top 300 pack. I did a fresh Mr Fusion install on a 64GB SD, then I grabbed the mount_cifs.sh and followed Dan's video to figure that part out. Everything is auto mount as if it was the local directory and it works great. Update_all.sh and the top 300 update script both found all their directories on the retroNAS no problem. Very smooth. The only thing that surprised me was that with the cifs mounted (all the time in my case), if I stfp into the mister's local IP I can delete the files out of the /media/fat/games/ and actually be deleting the off the retroNAS. It REALLY treats it like the local folder LOL

Excellent combination of software! Beautiful so smooth!

I'm glad it worked so smoothly! There's a lot of changes rolling through at the moment, so we're trying to minimise breakages at the moment. But the core/common things like basic file serving should all remain pretty solid.

[segamemister]

how does retronas deal with the sleep state of hdd when it idle for awhile does anyone know?

[Brendle]

Hi. The install guides I've found are all for installing RetroNAS to a RasperryPi, I'd like to install it to an old PC. It has to use Linux, right? Which lightweight Linux does it work with? My PC is pretty old and underpowered. I'm going to try AntiX Linux first, Debian 11 Bullseye looks a bit too beefy for my old computer. I'm hoping that after I get that done, the rest of the installation process is the same as it is with a Pi.

Currently RetroNAS requires Debian 11. I'd like to change that to be more distro agnostic long term, but that's where we're at currently.

Debian 11 will run on very low end hardware. I've got it personally loaded up on a 32bit Pentium M 1.5GHz, single core, 768MB RAM laptop and it runs fine on that. I run the LXQt desktop on that laptop which is very lightweight. You can bypass a GUI all together and use next to no resources.

I've got a short video on how to get Debian 11 on a VM. The process would be identical on an old laptop or desktop class system. Bob is aiming to have one out soon about how to repurpose an old laptop too (he's waiting for RetroNAS's newest GUI improvements to come through, but you can try now if you want).

https://youtu.be/i5VgHflLHNE'

Debian's official minimum requirements are a single core 1GHz CPU with 512MB RAM. I'd probably recommend at least 1GB though if you're going to load it up with services. SMB alone won't require a huge deal, but if you're going to add a few extra services or use our new GUI management, it'll help.

Cheers! Thanks for letting me know that Debian 11 runs on low end hardware, I installed it along with RetroNAS and besides a couple small bumps (because I'm fairly new to Linux) along the road, I've got it working.

I'm new to networking and NAS tech, will CD games running on a MiSTer Project DE10-Nano work alright? What I mean is that a Mega CD or PlayStation game sometimes plays the music from the files to simulate red book audio, will that kinda stuff be delayed (slower) over network cables? Also I assume they would be delayed more over wireless. I don't know exactly how the tech works though so I may be wrong. I haven't tried PlayStation 2 yet but in the past I once tried to play games over a network from my main PC and it was slow, the FMV in games was choppy because it couldn't stream it fast enough. It couldn't keep up.

Thank you for your time.

[elvis]

how does retronas deal with the sleep state of hdd when it idle for awhile does anyone know?

Sairuk added hard disk power management under the "Advanced Tools" menu a couple of weeks back. Check that out and see if it does what you need.

I'm new to networking and NAS tech, will CD games running on a MiSTer Project DE10-Nano work alright? What I mean is that a Mega CD or PlayStation game sometimes plays the music from the files to simulate red book audio, will that kinda stuff be delayed (slower) over network cables? Also I assume they would be delayed more over wireless. I don't know exactly how the tech works though so I may be wrong. I haven't tried PlayStation 2 yet but in the past I once tried to play games over a network from my main PC and it was slow, the FMV in games was choppy because it couldn't stream it fast enough. It couldn't keep up.

CD/ISO performance is fine. An RPi4 has a dedicated PCIE-attached Gigabit port that can sustain full gigabit speeds (real world 95MB/s in my testing), and likewise its USB3 port (specced at 5Gbit/s) can handle real world 300MB/s or more - more than enough to flood the network. Best device I could find was a very cheap NVME device in a USB3 converter that delivered that speed. I don't know if it can go faster with a better drive (probably).

MiSTer autonegotiates all the way up to SMB 3.1.1 as its connecting protocol (latest version of the SMB protocol suite), and RetroNAS (Samba specifically) likewise will reciprocate and communicate with MiSTer at that latest protocol version.

Pork Chop Express' testing matches my own figures. You'll get about 500Mbit/s (50MB/s) or so over SMB, limited by the DE10Nano's own IO capabilities (making an RPi4 about twice as fast in practice, and not the bottleneck):
https://misteraddons.com/blogs/news/mis ... d-shootout

To put that in perspective:
* A 1x CD-ROM delivers data at around 150KB /s
* A 24x CD-ROM delivers data at around 3.6 MB/s
* A 1x DVD-ROM delivers data at around 1.38 MB/s
* A 16x DVD-ROM delivers data at around 22 MB/s

And all optical drives have far worse latency than network, so loading ISOs over SMB will deliver lower latency (both seek and read) than reading a real optical disc on a real optical drive.

The stuttering most people experience with PS2 over SMB has nothing to do with network or disk performance. The PS2's 4x DVD-ROM delivers a peak of 5.28 MB/s of data, however real world a fraction of that (SD streaming video on PS2 often streams at 1/2 or 1/4 of that, as internal tracks on optical media are much slower than peak speeds due to lower angular velocity). Typically the stuttering comes down to bugs in OpenPS2Loader, or incorrect DMA settings on a per-game basis (certain games require certain settings to work). I've also found a LOT of people are running very out of date OpenPS2Loader builds. 1.1.0 is currently stable, with 1.2.0 in testing. If you're running some ancient version from the 2000s, try out a newer build and see how that goes.

The project is open source and available on GitHub. Don't download it from weird "scene" forums, download it directly from official repo instead:
https://github.com/ps2homebrew/Open-PS2-Loader/releases

Also, some people share via SMB over WiFi to a PC, and the packet loss kills it. If you're streaming data to things like PS2, GameCube, etc, absolutely you need wired Ethernet to avoid packet loss. Packets arriving consistently, on time, and in order are critical for older consoles with little buffering overhead. MiSTer (and Linux as the host OS handling virtual devices), alternatively, is a lot more forgiving, with far better caching and read-ahead at file and block levels.

[Brendle]

Thanks for the reply. That all sounds good, I'm glad to hear about the good network performance. MiSTer and PlayStation 2 are working great for me, it's good to see the Tekken Tag Tournament FMV intro run smoothly. That's always the game I test with and this is the first time it has ran smoothly.

Is there a way to use the actual internal hard drive of the Linux PC I'm using? I can only figure out how to play games from an external USB HDD. Also sorry, random other question - Is it possible to use RetroNAS over a network that isn't using my main router? In other words, a network switch or second router which isn't connected to the internet.

Also, are the services installed to the external drive or the drive that Linux Debian is installed on? Samba, PS2 SMB Config, 3DS QR Code Generator, etc. I ask because I am replacing the external HDD with a different one, so I'm wondering if I must reinstall these services.

[elvis]

Is there a way to use the actual internal hard drive of the Linux PC I'm using? I can only figure out how to play games from an external USB HDD.

Yes. You can use Cockpit to mount any existing hard disk. Then set the top level directory in the RetroNAS global configuration, run the permissions fix, and off you go.

Also sorry, random other question - Is it possible to use RetroNAS over a network that isn't using my main router? In other words, a network switch or second router which isn't connected to the internet.

If you're on a completely isolated network, you'll need to manually set up IP addresses on your devices (RetroNAS and whatever consoles you want to connect to). We're working on providing a DHCP server in RetroNAS soon so that it can be used on isolated networks.

Also, are the services installed to the external drive or the drive that Linux Debian is installed on? Samba, PS2 SMB Config, 3DS QR Code Generator, etc. I ask because I am replacing the external HDD with a different one, so I'm wondering if I must reinstall these services.

The services are run by the host Linux system, specifically the standard Debian service manager "systemd". Normally they're stored in /etc/systemd or /usr/lib/systemd, which are typically on your root filesystem, not the RetroNAS data disk.

RetroNAS manages both the service and the file locations. So yes, if you switch your data disk over to another server, you'll need to reinstall the services.

[seastalker]

elvis, THANK YOU for this RetroNAS project! I'd like to try this out and consolodate many old hard drives (internal, external, SDD, spinning platter) into one platform and this looks like IT. I've wanted a way to have a folder structure where MiSTer, retropie/hyperspin, retroarch, everdrive library setups can all exist with little to no need for duplicate rom collections [duplicate roms in smokemonster game pack collections are ok]. Maybe symlinks do this? Smoke's folder structure is as close to perfection as I have ever seen. A universal folder structure standard for all gaming across multiple platforms is the dream.

Maybe a future addition could simply be a text pop-up suggestion guiding people as to suggested best file format compatibility for archives? For example, PS1/Saturn might be able to run on space-saving .CHD format on MiSTer, but a caution about needing .BIN /.CUE for universal compatibility with running on real hardware, ODEs or emulators might be the icing on the cake. [It's just an example...] If more people adopted a standardized 'best' folder structure, future content creator tutorials would be perhaps easier for the masses to follow.

Perhaps beyond the scope of the project, but if this can run on a machine that also runs pfSense AND PLEX, I think a lot of old laptops will really get some love again. Probably PLEX media is already easy (movies, tv shows)... fans of the EmuVR project would especially benefit from an easy Plex handshake.

GREAT work regardless of these features!

[bbickell]

Hey all - I've noticed that the symlinks for the SNES rom location appear broken in my version of Retronas. I've also updated the software but for some reason \\retrosmb\mister\games\SNES doesn't point to \\retrosmb\retronas\roms\nintendo\snes on my setup.

Any suggestions? Not real handy with symlinks, but I could probably muddle my way through it if I need to configure this myself to fix.

[elvis]

Hey all - I've noticed that the symlinks for the SNES rom location appear broken in my version of Retronas. I've also updated the software but for some reason \\retrosmb\mister\games\SNES doesn't point to \\retrosmb\retronas\roms\nintendo\snes on my setup.

Any suggestions? Not real handy with symlinks, but I could probably muddle my way through it if I need to configure this myself to fix.

1) Go to \\retrosmb\retronas , which is the SMB top level of your configured storage (you'll see "mister" and "roms" folders within this - these are exposed via other SMB/CIFS shares too, but we're looking from the top level here)

2) Rename "mister" to "mister.old"

3) Re-run the "MiSTer FPGA CIFS config" tool in the RetroNAS install menu.

This will rebuild the symlinks and should point to the right place. Your "roms" dir will remain untouched.

[Hylian Peasant]

Hello elvis,

Nice application your are building. The idea of a NAS specifically tailored for (retro) gaming is very appealing.
I've installed it inside a Debian 11 VM and here is what I try to achieve.

My current use case :
1/ Own two MiSTers
2/ I mount directly my NAS on any of MiSTer filesystem in order to have a centralized roms and saves repository (both "/media/fat/games" and "/media/fat/saves" folders are mounted on the same NAS shared folder via CIFS/SMB)
3/ Can play any game on any MiSTer and use the latest save (or savestate) thanks to the centralized repo in the NAS

What I want to improve with RetroNAS :
1/ Use RetroNAS to handle all handy services and protocols stuff (safe and less safe) and all the symlinks (via Smokemonster SMDBs)
2/ Keep my NAS as the central repo for roms (with untouched romsets staying there) and also saves and savestates

After I installed Samba for Mister - MiSTer FPGA CIFS config, I noticed multiple new folders have been created inside "/data/retronas/" : bios, mister, roms, saves, savestates, wallpapers.

Questions :
1/Is there a plan to make symlinks inside "/data/retronas/mister/saves", "/data/retronas/mister/savestates" and "/data/retronas/mister/BIOS" targeting respectively "/data/retronas/saves/", "/data/retronas/savestates" and "/data/retronas/bios" ?
An even better idea would be to make those symlinks target respectively "/data/retronas/saves/MiSTerFPGA/", "/data/retronas/savestates/MiSTerFPGA" and "/data/retronas/bios/MiSTerFPGA/" in order to avoid issues in case saves and/or savestates not interoperable with other applications (e.g. different software emulators etc) and to handle MiSTer BIOS file structure.

2/ I want to mount my NAS on RetroNAS /data/retronas/ with the following folders on the root of my NAS shared folder : "roms", "saves" and "savestates".
Do you see any red flags going this way ? (from what I read, RetroNAS seems to be mostly aiming to also be the local file repo).
If yes, maybe adding as an option inside install list item could be a good idea ?

[elvis]

1/Is there a plan to make symlinks inside "/data/retronas/mister/saves", "/data/retronas/mister/savestates" and "/data/retronas/mister/BIOS" targeting respectively "/data/retronas/saves/", "/data/retronas/savestates" and "/data/retronas/bios" ?

I believe Sairuk has completed this work now.

2/ I want to mount my NAS on RetroNAS /data/retronas/ with the following folders on the root of my NAS shared folder : "roms", "saves" and "savestates".

This is available now. Documentation here:
https://github.com/danmons/retronas/wik ... ce-sharing

[Hylian Peasant]

Hello Elvis,

Thanks for the replies.
At that time, I registered to github to post and get assistance.
I confirm that everything work like a charm with Sairuk help.

Thanks

[djsquare]

I use RetroNAS for 3 MiSTers have around the house and it's truly wonderful. I don't need to transfer save files between MiSTers any longer. I have one central location to manage everything. I have every single PS1 game at my finger tips (even though I have no time to play) and many other full disc sets. It also works amazing for PS2 and Gamecube. I would love to try the PS3 someday with it.

Thank you Elvis for RetroNAS

[Malor]

Just thought I'd say that I'm using a machine running Ubuntu with ZFS, and it's a very nice setup. ZFS has snapshot capability, and there's a program called sanoid that will make hourly, daily, weekly, and monthly snapshots for you with minimal effort. This lets you go 'into the past', and fish out old versions of files, which can sometimes be very handy.

I'd recommend using it with at least a mirror; ZFS on a single drive will tell you about data being damaged, but can't fix it. If you run at least a mirror, it will often be able to use the other drive to get a good version of any data that's been damaged.

I use Samba as the filesharing protocol, and moved the directories BIOS, Cheats, config, docs, games, saves, and savestates to /media/fat/cifs, and then created symlinks in the original locations. This has been working beautifully, and ZFS saved my butt once already when I tried to hexedit my Final Fantasy 3 save, and somehow borked it. I deleted my manual backup before testing fully, because I didn't think I'd actually changed anything. Oops! Snapshots ftw.

edit: also, a network share is usually faster than a local hard drive, because the Ethernet port has more bandwidth than the USB2 ports.

[elvis]

ZFS and BtrFS are both excellent options for storage. For RetroNAS on lower power devices I recommend BtrFS as a backing store (ZFS or BtrFS are both excellent on higher powered devices, and each has a list of pros and cons that are down to individual preference, which I'm happy to list here if people want me to).

I've got a small amount of BtrFS documentation on the RetroNAS wiki here:
https://github.com/danmons/retronas/wiki/BtrFS

It's incomplete though. I'm missing sections on
* Multi disk redundancy
* Snapshots
* Deduplication

I'll try to fill these out in the coming weeks/months. I'm also waiting on a BtrFS module to be added to Cockpit, so hopefully all of this is easier for people, and doesn't require command line tools to set it up. Still lots to do yet to make RetroNAS more user friendly.

[Malor]

btrfs is okay if you use it for one filesystem per partition or disk. If you expand past that in any way, you are likely to run into horrific bugs and huge data loss. Even multiple filesystems on one backing store can give you trouble, and trying to use it for RAID is pretty much playing Russian roulette. It's not a question of if your data will die, but when.

ZFS works for pretty much any application, and it's particularly good at running big RAIDs of dozens of disks. But it's not really well integrated with Linux; it's deliberately licensed in a way that means it can't be directly incorporated, or at least that's the overall community opinion. Ubuntu has been bucking that opinion, however, and shipping it included.

Included or not, however, it remains a patch to the Linux kernel, and it feels almost like it's running alongside as a second operating system. It wants to control everything on its own, and is filled with layering violations. It is deeply weird from a Linux perspective, and takes some study to understand.

That said, if you can tolerate how differently it does everything, it is incredibly robust. If there is any way to recover valid data out of your filesystem, it will find it. I saw a screen capture of a ZFS mirrored pair with literally hundreds of thousands (maybe millions?) of errors, yet the filesystem had never lost data. Something was horribly wrong, either with the drives, the cabling, or the interface, but since the bad spots on both drives weren't in the same place at the same time, ZFS had lost zero bytes.

The full integration down to the bare metal is what makes it so robust; by completely ignoring the normal Linux layering, it can easily transmit data anywhere in its own stack for recovery. If a disk is failing, any ZFS code that needs to know that, does. On the regular Linux setup of disks -> md -> (optional) LUKS crypto -> (optional) LVM, every layer abstracts things and hides problems underneath. The various layers have only precisely defined APIs that make it far harder to actually get good data out of the filesystem. The mdraid layer, for instance, doesn't do checksumming of any kind, so while it can detect that it's getting bad data from a set of blocks, and while it may be able to correct the error if it involves only one disk, it has no built-in way to know which disk has the bad data. If the drive itself isn't reporting errors, mdraid can only (maybe) fix the output. And it can't report to upper layers that something hinky is going on, either, without throwing an outright error and dropping data.

ZFS doesn't have those problems, because it runs everything itself. This makes it feel very strange, but you will know exactly which disks are giving you problems, exactly when it starts happening, and assuming you used a mirror or enough parity data, you're gonna get your data back out.

The ZFS devs are just absolutely insane about reliability, which probably isn't that important for a Mister share, but if you intend to use the NAS for other stuff, you may really appreciate their crazy focus. Its biggest downside is that it takes study. I spent probably close to a fulltime week learning how it worked before I felt confident enough to build my NAS. But, wow, it's been great. I love love love snapshots.

You can get NAS software or actual physical devices with ZFS already built in, so you don't have to spend the same kind of learning time I did. My scenario was a custom-built PC with a number of drives, where I installed Ubuntu and self-configured ZFS. It doesn't have to be that painful.

[elvis]

btrfs is okay if you use it for one filesystem per partition or disk. If you expand past that in any way, you are likely to run into horrific bugs and huge data loss.

Grossly untrue. I'm running petabytes of BtrFS storage on multi-disk setups for the better part of the last 8 years in very large commercial sites. All is well.

Statements like these are almost always made by people who don't use it, typically based on 5 year old information, and base their assertions on outdated Internet rumours. I use it in the heat of battle every day, and my statements are made on large scale deployments in real world scenarios on modern deployments, not hypotheticals and 5 year old Reddit posts.

ZFS works for pretty much any application

ZFS and BtrFS both have long lists of pros and cons. Neither are suited to every application, and there are notable instances where both fall short of a given scenario. That doesn't make either one bad. No software can meet 100% of the requirements of 100% of users. This is why choice is invaluable.

Similar to BtrFS deployments, I *also* run petabytes of ZFS storage in commercial deployments. And the reason that some are BtrFS and some are ZFS come down to the point above - there's no single file system to suite 100% of requirements. Even ZFS and BtrFS have their limits, and there are numerous other file systems some of my customers rely on that are neither of these options, again for the same "doesn't suit their requirements" reasons.

BtrFS has it's place. It's not a silver bullet, but neither is anything else. And as above, claims of "horrific bugs and data loss" at this point are Internet wives tales repeated by people who rarely use these tools in real world environments, or read a post from 5 years back and assume nothing has changed.

[seastalker]

Finally started testing this solution. Using a Rpi3 (for now). I followed both guide tutorials on the github page and my SD card works with the OS install and the retronas install. I got past the 'install things' and installed everything desired from the list.

The issue I'm facing: Using the retronas menus, when I select to test/check on status of the many programs, I get failures/errors. They all SEEMED to install fine from the list but don't check out ok here. For example, testing Cockpit, I get:


systemctl --no-pager --full status cockpit

Unit cockpit.service could not be found.

Press [Enter] to continue...

If I put in the IP address in a browser with :9090 after it, I am unable to connect. After trying RetroRGB Bob's way, I even redid the install using SSH with Putty, and was successful up to that same point.

Any ideas? Thanks! I can test and list the output of other service checks if needed.

[seastalker]

Got it to finally work, but it can be frustrating not to know what the problem was. I just tried installing Cockpit over itself a few times and today the install just decided to work after reinstalling. Can get into the cockpit gui now.

[seastalker]

ABSOLUTELY LOVE RETRONAS!!! Seriously- I hope EVERYONE tries it out- you won't go back. IMHO, I feel RetroNAS should have it's own official thread on the forum.

@Elvis - Some questions I hope you might have suggestions for:

1. If installing Debian as a 64-bit full desktop base OS, how do we add more external drives/PLEX MEDIA SERVER to work with RetroNAS?
2. If someone installs ALL optional items in RetroNAS, which folder directory is best to store a large MUSIC collection?
3. I am new to Symbolic links but love them! Do you have a downloadable empty-folder structure for people to drag/drop them for backup drives? I could see your folder organization being THE standard to follow, and it would be great in general on NTFS drives for local Windows access. Otherwise, is it better to just setup RetroNAS on another external drive and then copy everything to it, roms and all?

Many thanks!!

[elvis]

1. If installing Debian as a 64-bit full desktop base OS, how do we add more external drives/PLEX MEDIA SERVER to work with RetroNAS?

RetroNAS is mostly an installer for different services. We aim to be as non-breaking as possible with a vanilla Debian system, so any regular guides for installing more storage or tools like Plex should work fine and not break RetroNAS (or vice versa).

2. If someone installs ALL optional items in RetroNAS, which folder directory is best to store a large MUSIC collection?

I haven't quite got around to music stuff yet. Probably just put a "music" folder in your top level RetroNAS share and share out from there.

I have plans for RetroNAS to play audio files via the RPi or PC audio out, so old tape loading systems can load games stored as digital audio files (or special formats like C64 TAP) straight from RetroNAS.

3. I am new to Symbolic links but love them! Do you have a downloadable empty-folder structure for people to drag/drop them for backup drives? I could see your folder organization being THE standard to follow, and it would be great in general on NTFS drives for local Windows access. Otherwise, is it better to just setup RetroNAS on another external drive and then copy everything to it, roms and all?

I'm wary of proclaiming anything I do as "the" standard. I'm an amateur preservationist as well, and there are already a lot of competing standards for ROM paths out there. Our challenge was to try and unify them so that users could share to as many different platforms as possible without needing to endlessly copy ROMs to multiple folders, or waste space with multiple copies.

But I think XKCD sum it up best when people try to make new standards:
https://m.xkcd.com/927/

Do we have an empty folder structure somewhere? Not currently. I'll see if it's something we can make maybe as an exportable backup tree. I'll have a think about that.

[ALCF98]

Is there a guide on how to setup a a private network for RetroNAS?
It says to make sure it’s behind a router but also separate from rest of the network. Does that mean I need two routers?

[Malor]

"Separate from the rest of the network" doesn't even make sense for a NAS. A fileserver needs to be reachable, or it's not a fileserver.

Maybe they're giving you bogus instructions as an excuse for poor security? "You put it on the same network as the clients, so when your whole network got hacked, it's Not Our Fault."

I mean, yes, you can set up a separate firewall and then open only specific ports to and from RetroNAS, but that's a ridiculous amount of pain to go through. The project should be as safe to use as any other server, or you shouldn't use it at all. Pretty much every other fileserver in the world is designed to just be in your own private network.

Making sure any NAS is unreachable from the outside world is simple sense. Needing more security than that most likely means it's a bad project.

[ALCF98]

It’s entirely possible that I’m miss understanding it.

"Separate from the rest of the network" doesn't even make sense for a NAS. A fileserver needs to be reachable, or it's not a fileserver.

Maybe they're giving you bogus instructions as an excuse for poor security? "You put it on the same network as the clients, so when your whole network got hacked, it's Not Our Fault."

I mean, yes, you can set up a separate firewall and then open only specific ports to and from RetroNAS, but that's a ridiculous amount of pain to go through. The project should be as safe to use as any other server, or you shouldn't use it at all. Pretty much every other fileserver in the world is designed to just be in your own private network.

Making sure any NAS is unreachable from the outside world is simple sense. Needing more security than that most likely means it's a bad project.

[Malor]

Ah, I see, it's a *deliberately* insecure product, because the old protocols are insecure. Well, at least they're telling you.

A) Probably the easiest solution is just to airgap it. Buy a separate 8-port switch, wire all your retro devices there, and don't have any connection to the Internet. If you want new stuff, download it to a USB key, and sneakernet it over to the RetroNAS box. That should be entirely safe.

B) If you really want to be able to get to the Internet from that network, putting a separate router/firewall between the two networks should be reasonably safe. You'd connect the new router's WAN port to a client port on your existing network. Doing it that way means that all the retro devices can attack your outer network, but since no evil software should ever get into that network, it's not that big a deal. You can open ports to allow your trusted/outer network back into the retro/inner network. By default the retro network will have full access to the trusted area. Overall security here is not great, but much better than just sticking everything on the same net. If you have ports open from trusted to retro, however, and an attacker can exploit one, then they can launch from the exploited retro box into a full network compromise.

In a way, this is an inversion of security; the retro/inner network is protected from the outer/trusted network, which is kinda dumb. It would be better to do it the other way, where the retro network is outer and the trusted network is inner, but then all your trusted devices are dealing with double NAT, which can be a real pain if you need to forward ports from the outside. You end up having to do all forwards on two routers instead of one.

C) A more complex setup is using a multi-port firewall and putting the retro devices on a separate LAN network, side by side with the internal network. This means that the retro devices have no access to the rest of your network. However, firewall rules in multi-private-net configurations can get pretty hairy. This will allow cross-network communication if you choose, but again, getting the rules correct takes serious thought. Getting this solution correct is damn difficult if you've never done it before.

D) Yet another way to do that would be setting up a guest network on your wireless net; they typically don't allow any traffic back to the trusted network. Set up an AP in client bridge mode, where it's a client connected to the guest network, and then all your devices are on the guest network and can't reach the trusted network. In most cases, this will not allow any cross-communication, but it's pretty easy, and much safer than Option B. Unlike option C, you will probably not be able to have any cross traffic between the networks.

Option A is trivially easy and the safest overall option. The best way to keep old boxes safe is to not allow them on the Internet at all.

Option B is easy, and safe as long as you keep malware out of the retro network, and don't open ports into the retro network from the trusted network.

Option C is very advanced, probably ten times harder than the other options, but starts out perfectly safe, and is flexible enough to allow any ports anywhere you want. You can render this option unsafe if you make poor choices about opening ports, however. Expect to spend a long time learning how this works. You will probably need a small dedicated Linux firewall/router. Mainstream consumer hardware will probably not do what you need.

Option D is about as safe as Option C by default (the best security short of the Option A airgap), but will probably have no flexibility. Neither the retro nor the trusted networks can see or interact with each other. If you want new files, you'll have to either directly download them to the NAS or the target retro box via Internet, or use sneakernet to bring a USB key over.

My overall advice would be to start with Option A, the airgap. If you find you really need Internet access, graduate to Option D (guest wireless network). Only if you really need cross-network communication, or if your wireless guest network is too slow, should you do B or C.