VOGONS


First post, by Pierre32

User metadata
Rank Oldbie
Rank
Oldbie

I'm not the author - that credit goes to Dan Mons. I've been one of the users helping to test RetroNAS, and today it's had a bit of an official launch on the RetroRGB channel:

Introducing RetroNAS

RetroNAS on github (including detailed wiki)
Video tutorials
OCAU dev thread

What is it? A set of open source tools for your Raspberry Pi or other Linux box, enabling you to set up a NAS for your retro machines with a single installer, complete with slick menu system. It makes all of these tools very simple and accessible for regular folk, like me.

RetroNAS menu.jpg
Filename
RetroNAS menu.jpg
File size
155.8 KiB
Views
6203 views
File license
Public domain

So far it supports the following:

  • MS-DOS and clones such as PC-DOS and FreeDOS
  • Microsoft Windows 95 and up
  • Apple GS/OS, Classic Mac System 6 and System 7
  • Apple Mac OS8, OS9, OS X 10.0 and up
  • Atari ST with FTP client or HTTP browser
  • Amiga Workbench 3.X and up with FTP client or HTTP browser
  • Nintendo 3DS with Homebrew Channel and FBI installer
  • Sony PlayStation 2 with OpenPS2Loader
  • Sony PlayStation 3 with CFW/HEN and webMAN-MOD
  • Microsoft XBox 360 with JTAG/RGH, custom dash and ConnectX plugin
  • MiSTer FPGA

I've been running it on a Pi 4, serving up my library to my DOS, 9x and XP machines. No more physical media for file transfers. In many cases I can even just run software or mount ISOs straight off the network share. It's changed the game to the point where even slinging a CF card around feels like work now. I manage my library from my modern rig, and it's right there ready to go when I fire up a retro rig. Samba is the main workhorse for me, but I also run EtherDFS for the DOS machine, and do a little FTP and Telnet on the side. I'm also using GOGrepo to sync my GOG library straight to the NAS. And Cockpit, which allows me to manage settings from a modern web browser.

copckpit.png
Filename
copckpit.png
File size
80.33 KiB
Views
6203 views
File license
Public domain

If you have the knowledge and skill you might have been using a bunch of these tools already. What Dan has done here is make them extremely accessible to everyone. I love the pants off this project, and just wanted to share it now that it's gone live.

If you have a later model Pi sitting around (or an existing NAS, old laptop or even a VM) it's worth taking for a spin.

Reply 1 of 68, by Pierre32

User metadata
Rank Oldbie
Rank
Oldbie

As DOS will probably be the primary interest here, I want to talk a little more about that. Compared to Windows (where a Samba share will Just Work if you have networking set up) getting DOS talking requires extra steps on the DOS side. RetroNAS provides EtherDFS, but just the server component of course. So you need to install the EtherDFS client on your DOS machine too.

How RetroNAS shares media (currently)
RetroNAS asks you for the 'top level directory' you want to use. This becomes the root folder of your network share, for any retro machine or protocol that connects. Each thing gets its own subfolder (dos, windows, ps2, etc). This is brilliant for simplicity, but if you stray from the script like I did, it can introduce a challenge.

EtherDFS requires a FAT filesystem
My network storage was an NTFS volume, so I had to configure it with a separate FAT partition - effectively becoming a second 'top level directory.' RetroNAS is not currently equipped for this, so I had to jump into the ethersrv and samba confs to manually add the second location.

Dan has plans to address this scenario, but in the meantime avoiding it is simple: Just use a single FAT volume as your network share. The volume can be as big as you like.

Running software over EtherDFS
EtherDFS is best used for transfer only in my experience. Attempting to actually run software over the network has been a pretty mixed bag. From some posts on OCAU, it almost seems like FreeDOS has a better success rate than MS DOS in this regard. But it's fun to try out some "streaming", including mounting ISOs over the network. Doing that requires SHSUCD which again, is client stuff not provided by RetroNAS.

FTP, Telnet etc
If you install these RetroNAS services, you will also need to install mTCP on the DOS side.

DOS file manager
Obviously a nice file manager on the DOS side speeds up management. Strangely I've found Norton Commander to be less than robust doing network transfers, sometimes not grabbing all the contents of a folder. Doing the same job with xcopy presents no such issues. I've now switched to DOS Navigator and so far, so good.

Reply 2 of 68, by elvis

User metadata
Rank Newbie
Rank
Newbie

Hi everyone, I'm the author of this thing. And thank you @Pierre32 for starting this thread, not to mention the extensive testing and feedback you've already helped me with. Invaluable stuff!

This got a wee bit of media today on RetroRGB for MiSTer and PlayStation 2 compatibility, but I want to emphasise that those projects are only a small part of what I'm aiming for.

I'm hoping I can get some good feedback from VOGONS members on the computing side. The posts above cover most of what's working now, and this is the list of things I want to add (or at least research):
https://github.com/danmons/retronas/blob/main/IDEAS.md

The goal is to make a device that's a central hub for anything. I want to be able to have a Win95 machine connect to archive.org and pull down files, or a UNIX System V machine NFSv2 connect for storage, or an Amiga pppd connect and pull files down via HTTP or FTP, or a DOS machine share files via EtherDFS, or an Apple II GS running GS/OS System 6 copying files over AppleTalk, and all at the same time as bleeding edge Windows/Mac/Linux desktops using it to push and pull files via SMB/FTP/SFTP/AFP or other modern protocols. Rinse and repeat for anything that ever had some sort of network/IO/communication hardware, really.

Obviously all of these things exist - I'm not "creating" anything here. I'm just collating a large amount of open source stuff developed by people much, much smarter than me, and bundling them all together in one place in a way that's hopefully a little easier than 100% DIY for people who aren't Linux users normally. The interface admittedly sucks (SSH in and use dialog menus), but I've already got offers from people to extend it to a web interface, so that's nice. I'm not a web dev, so I'll stick to the current menus as my primary focus.

I've got various USB and GPIO/TTL serial devices sitting on my desk right now, so R233 / null modem / ppp support is high on my want list. I have DOS and Win9X equipment I can test. The goal there is to have them communicating over file sharing protocols and/or having Internet access. After that, I need help from anyone with a real Amiga, AtariST or other device with serial/ppp compatibility to test things further.

Since going public I've also had people offer ideas things I forgot existed (DECnet was one), or had never heard of (TNFS for ZX Spectrum with Spectranet/FujiNet). These are exactly the sorts of things I want to add in. I also found someone working on a Netatalk2.X modernisation project (backporting fixes and enhancements, and fixing all the good stuff the upstream project removed in Netatalk3.X), which I've been testing with Apple IIGS, System 6, OS9 and OSX with good success rates.

On the documentation side, I've been busy making videos for as many of the services on offer as possible. A big missing piece right now is EtherDFS+FAT, where I need to do a much better job of explaining how to have a dedicated FAT mount for that. I want to include (non-mandatory) options like:
* Partitioning a single disk into mixed ext4 and FAT
* Using LVM to volume manage a disk wit a dedicated FAT volume
* Create a loopback file formatted as FAT and mounted in the EtherDFS export location
* Using a FAT-formatted USB stick for EtherDFS, mounted below the RetroNAS tree running standard ext4

It's these things that I hope will make the tool more useful to people (or even if they never use it, and want to roll their own solution, that's cool too).

The project is MIT licensed. If people want to pinch my installers, compiler scripts, Ansible code (the stuff that drives most of the installers), configuration files or whatever, be my guest. As above, I don't feel I've really created anything here per se, more just assembled a bunch of really cool things written by much smarter people.

The GitHub is open to discussions and issues, and likewise I'll check in here frequently for feedback, ideas, criticisms or whatever is on offer.

The overwhelming goal is inclusion - as many systems as possible, and in a way that's as cheap/free as possible (RPi, old computer, VM, etc as the target platform to deploy on). Worth mentioning that security is almost non-existent. Everything runs pretty open with very little in the way of security or encryption due to the era of protocols on offer. But I figure audiences like VOGONS are more than well versed in managing old computers inside modern networks, and don't need lecturing about that.

So again, thank you Pierre32 for the blurb and the assistance to date. And thanks in advance to anyone here who is willing to give it a try, or offer feedback and ideas either here or on GitHub.

Reply 3 of 68, by davidrg

User metadata
Rank Member
Rank
Member

Its really a shame IPX was cut from the Linux kernel a few years back. There is a Netware server implementation for Linux (Mars NWE) which would have been great for something like this.

Why? Compared to the Microsoft SMB/Lanman client for DOS, the NetWare 32bit DOS client is absurdly memory efficient; it will use at most 4KB of conventional memory (and none at all if you've got EMM386 loaded). If you're on a 286 or older (or a version of DOS older than 5.0) its still significantly more light-weight than the Microsoft client while doing all the same things. Plus there are clients for OS/2 v1.2+ that don't require you to have the special Connect edition or the sold-separately network bits.

Video here showing Mars NWE in action: https://www.youtube.com/watch?v=MZ2aQs2706A

Reply 4 of 68, by elvis

User metadata
Rank Newbie
Rank
Newbie
davidrg wrote on 2022-01-31, 06:30:

Its really a shame IPX was cut from the Linux kernel a few years back. There is a Netware server implementation for Linux (Mars NWE) which would have been great for something like this.

I don't know a whole lot about IPX, but is the project/code still maintained somewhere? If it's something I can compile against a current kernel, link in, load as a module and enable, that should be fine.

RetroNAS already installs a few things from source (WebOne and .Net, ps3netsrv, the new Netatalk2 project for non-IP AppleTalk, etc). No problems doing that for another tool/service/protocol if it exists and can be compiled with a current compiler and toolchain.

davidrg wrote on 2022-01-31, 06:30:

Why?

I honestly don't mind the "why" part. If someone wants it, I'll add it in (assuming I can find/compile it). Most things in RetroNAS are optional, so if people don't want it, they don't have to install it.

Reply 5 of 68, by keropi

User metadata
Rank l33t++
Rank
l33t++

welcome aboard elvis!
I saw RETRORGB's videos yesterday - retronas is indeed a great way to manage content when it comes to mister/ps2/whatever can use network shares easily
thanks for sharing it!

I'll wait and see what developments will be on the 286/386/486 area because IMHO with the software we have (retronas has nothing to do with it) it's just too cumbersome.
Memory/drivers aside what is really off-putting is that you have to copy a game locally to run it - not a problem with a 500kb one but if you want to run a 10~15mb one? that can take some time with a 386 and you know we are impatient 🤣 🤣 🤣 (unless my assumptions on this are wrong ofcourse ...)

anyways keep up the good work!!!!

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 6 of 68, by Pierre32

User metadata
Rank Oldbie
Rank
Oldbie

I do wish my 386 was running at the moment so I could test. I previously used FTP transfers on that machine (before RetroNAS existed) and it was slow stuff. I'm on a Pentium 200 now and EtherDFS transfers are pretty snappy - think about a minute for an ISO. On the same old SMC NIC for what that's worth! I would be interested to hear how older machines perform with the same tools. Hope to see some Vogons testers.

Reply 7 of 68, by elvis

User metadata
Rank Newbie
Rank
Newbie
keropi wrote on 2022-01-31, 07:12:

you have to copy a game locally to run it

Pierre32 and a few others have been helping me out a lot with testing EtherDFS in particular. It's not 100%, but so far it seems to really be quite competent at removing the need to copy things locally for simpler software.

The other crazy thing they've been testing is SHSUCDHD over EtherDFS (ISO image sits on the EtherDFS share, SHSUCDHD sees that as a real DOS drive and makes the virtual device without fuss, SHSUCDX mounts it as a drive letter).

Obviously redbook audio doesn't work (would be wonderful to see BIN/CUE support one day, but that's way over my head). But absolutely mind blowing that it works as well as it does .

A couple of screenshots showing speeds at the bottom of this wiki page:
https://github.com/danmons/retronas/wiki/EtherDFS

Reply 8 of 68, by davidrg

User metadata
Rank Member
Rank
Member
elvis wrote on 2022-01-31, 07:03:
I don't know a whole lot about IPX, but is the project/code still maintained somewhere? If it's something I can compile against […]
Show full quote
davidrg wrote on 2022-01-31, 06:30:

Its really a shame IPX was cut from the Linux kernel a few years back. There is a Netware server implementation for Linux (Mars NWE) which would have been great for something like this.

I don't know a whole lot about IPX, but is the project/code still maintained somewhere? If it's something I can compile against a current kernel, link in, load as a module and enable, that should be fine.

RetroNAS already installs a few things from source (WebOne and .Net, ps3netsrv, the new Netatalk2 project for non-IP AppleTalk, etc). No problems doing that for another tool/service/protocol if it exists and can be compiled with a current compiler and toolchain.

davidrg wrote on 2022-01-31, 06:30:

Why?

I honestly don't mind the "why" part. If someone wants it, I'll add it in (assuming I can find/compile it). Most things in RetroNAS are optional, so if people don't want it, they don't have to install it.

Mars-NWE was last released in 1998 so not really maintained anymore but apparently does work on a modern linux distro as long as you're running Linux kernel 4.14.x or older as this was the last version to include support for the IPX protocol. Running an old linux kernel just to support DOS NetWare Clients isn't really sustainable long-term which is why I thought it was such a shame IPX support had been removed - if it wasn't for that adding support to RetroNAS would have been pretty feasible.

However, I just stumbled on this while trying to find when protocol support was actually removed: https://github.com/pasis/ipx - someone has extracted the IPX code from an old kernel and turned it into a kernel module for Linux 4.18 and up! This is kind of exciting (to me at least) - I might just have to have a go at setting Mars-NWE on a spare Pi this week!

As a side note: Running DOS apps straight from NetWare network drives does seem to work just fine. I guess this is something Novell really needed to make sure worked properly given network booting DOS from NetWare servers was a thing.

Reply 9 of 68, by elvis

User metadata
Rank Newbie
Rank
Newbie
davidrg wrote on 2022-01-31, 07:43:

However, I just stumbled on this while trying to find when protocol support was actually removed: https://github.com/pasis/ipx - someone has extracted the IPX code from an old kernel and turned it into a kernel module for Linux 4.18 and up! This is kind of exciting (to me at least) - I might just have to have a go at setting Mars-NWE on a spare Pi this week!

That looks really promising. Keen to hear how you go.

I've bookmarked that site in IDEAS.md just for my own poor memory.

Reply 10 of 68, by Firtasik

User metadata
Rank Oldbie
Rank
Oldbie

Samba is going to remove SMB 1.0:

SMB1 CORE and LANMAN1 protocol wildcard copy, unlink and rename removed ======================================================== […]
Show full quote

SMB1 CORE and LANMAN1 protocol wildcard copy, unlink and rename removed
=======================================================================

In preparation for the removal of the SMB1 server, the unused
SMB1 command SMB_COM_COPY (SMB1 command number 0x29) has been
removed from the Samba smbd server. In addition, the ability
to process file name wildcards in requests using the SMB1 commands
SMB_COM_COPY (SMB1 command number 0x2A), SMB_COM_RENAME (SMB1 command
number 0x7), SMB_COM_NT_RENAME (SMB1 command number 0xA5) and
SMB_COM_DELETE (SMB1 command number 0x6) have been removed.

This only affects clients using MS-DOS based versions of
SMB1, the last release of which was Windows 98. Users requiring
support for these features will need to use older versions
of Samba.

https://download.samba.org/pub/samba/rc/samba … c1.WHATSNEW.txt

11 1 111 11 1 1 1 1 1 11 1 1 111 1 111 1 1 1 1 111

Reply 11 of 68, by davidrg

User metadata
Rank Member
Rank
Member
Firtasik wrote on 2022-01-31, 10:55:

Samba is going to remove SMB 1.0:

Good thing it looks like Mars-NWE works! I spent a few minutes setting it up on a spare Raspberry Pi 4 and I'm able to login from DOS using some version of Client32. Not very smoothly though but this is just a first attempt by someone who has never used Mars-NWE before.

I installed the IPX kernel module using DKMS with these instructions. I then setup Mars-NWE using these instructions with the following changes:

  • I skipped building the linux kernel as the IPX kernel module is providing what I need there
  • Only made the following changes to the config file:
    • In section 2 I gave my server a name (MARS)
    • In section 12 I gave the SUPERVISOR user a password
  • Didn't follow the guides client setup instructions as those are for a properly antique (obsolete since 1993) version that's only worth using if you're on an 8086 or running DOS 3.0. I'm using Novell Client32 v2.71 from October 1998 which I already had installed (installing it is pretty easy).

I initially made the config change the guide suggested to section 3 but Mars-NWE refused to start so I undid the change.

From there I was able to login with

F:
login MARS/SUPERVISOR

The login program complained a lot while running whatever login script Mars-NWE supplied for the SUPERVISOR user but this perhaps shouldn't be surprising. The NetWare client had automatically attached to my local NetWare 4.11 server so I was using the NetWare 4.11 login program to try and login to Mars-NWE. Possibly the NetWare 3.12 login program or the one that comes with Mars-NWE would have worked better. Tomorrow I'll need to see if I can track down the login script Mars-NWE is supplying and customise it to be less problematic.

Once the login script had finished throwing errors I was all logged in with drive M mapped to MARS\SYS: (/var/mars_nwe/SYS on the pi):
mars-login.png

Edit: Found the login script. Its /var/mars_nwe/SYS/public/net$log.dat. It errors a bunch because the default login script is a complete mess. Its not an example minimal login script, its a copy of a login script from a school or something. Its trying to map a pile of drives to shares that don't exist or shares on other servers as well as running various batch files, etc. After commenting out pretty much everything I can login without errors. Logging in from Windows 3.11 works fine too.

Could probably do with a bunch of testing but I think this would be a neat addition to RetroNAS!

Reply 12 of 68, by elvis

User metadata
Rank Newbie
Rank
Newbie
Firtasik wrote on 2022-01-31, 10:55:

Samba is going to remove SMB 1.0

Yeah this weighs on my mind. They've been threatening for full scale removal for some time, which I think is a real problem for retro computing enthusiasts.

Debian 11 was released August 2021, and has a 5 year support window, taking us through to August 2026. It currently offers Samba 4.13 and will remain on that (backporting fixes). So at least until then, everything is fine.

After then, it's going to come down to source compiles. And I think this is going to go the same way as Netatalk2.x. For example, I'm currently pushing an old .deb of Netatalk2, but have since found this project, which I'm going to use to replace my current binary-install method with their source code (I can write compiler scripts and Ansible playbooks to handle that, have some in testing now and they're working well):

https://github.com/rdmark/Netatalk-2.x

That person has backported a number of community patches floating about the Internet into the Netatalk 2.x tree, and then fixed up the code to make it compile and run on a modern gcc/glibc setup. What's brilliant about that is things like AppleTalk (the non-IP protocol), A2BOOT, Timelord and other things are all now re-enabled (these were all tragically removed in Netatalk 3). That person single headedly has resurrected network file and print sharing for 15 years worth of Apple hardware.

With any luck, we'll see the community do the same for Samba. If Samba 4.13-ish (I think more was deprecated again in 4.14 and 4.15) can be kept alive - i.e.: just able to be compiled in future versions of gcc/llvm, we're in a good spot for maybe another 10-15 years.

Unfortunately I don't have these skills. But I'm hoping enough people care about a functional SMB stack for Win95 that someone, somewhere keeps it going.

davidrg wrote on 2022-01-31, 11:25:

Could probably do with a bunch of testing but I think this would be a neat addition to RetroNAS!

This is brilliant, thank you so much. I'll take some notes down and add this in over the next couple of weeks.

Reply 13 of 68, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

TrueNAS with latest updates still working fine for 3.51/95+ (Tested) but it's just a matter of time. Yes FTP or SFTP can be used but it's so inconvenient.

I did run into this awhile back, haven't had a chance to look at it:
Possibility of SMB2/3 on 9x-NT3-4x?

Another option that wouldn't require anything on the client would be an SMB proxy. Intent would be to strip everything not needed from SMB except for what's needed to send and receive the traffic. Since proxies are needed for web traffic for these VMs then would make sense to add that functionality in. Heck, add a cache in there to make it even more useful. Of course you can't forget about NetBIOS so if that is removed then that would need to be setup as well.

I'm confused by https://download.samba.org/pub/samba/rc/samba … c1.WHATSNEW.txt

This only affects clients using MS-DOS based versions of SMB1, the last release of which was Windows 98

That is so poorly worded.
Did they forget that MS-DOS exists in Windows 98SE or Windows ME?
What about versions of DOS that don't come with Windows, they do know DOS existed before Windows right?
Are they talking about LANMAN and not NT1 so networking in Windows in 9x,3.51,NT4 are unaffected?
Thinking anything <= NT 3.50 would be affected. Don't have my 3.50 VM setup yet (working on it!) so can't verify but I know 3.51 works.

How To Ask Questions The Smart Way
Make your games work offline

Reply 14 of 68, by darry

User metadata
Rank l33t++
Rank
l33t++
DosFreak wrote on 2022-02-01, 00:33:
TrueNAS with latest updates still working fine for 3.51/95+ (Tested) but it's just a matter of time. Yes FTP or SFTP can be use […]
Show full quote

TrueNAS with latest updates still working fine for 3.51/95+ (Tested) but it's just a matter of time. Yes FTP or SFTP can be used but it's so inconvenient.

I did run into this awhile back, haven't had a chance to look at it:
Possibility of SMB2/3 on 9x-NT3-4x?

Another option that wouldn't require anything on the client would be an SMB proxy. Intent would be to strip everything not needed from SMB except for what's needed to send and receive the traffic. Since proxies are needed for web traffic for these VMs then would make sense to add that functionality in. Heck, add a cache in there to make it even more useful. Of course you can't forget about NetBIOS so if that is removed then that would need to be setup as well.

I'm confused by https://download.samba.org/pub/samba/rc/samba … c1.WHATSNEW.txt

This only affects clients using MS-DOS based versions of SMB1, the last release of which was Windows 98

That is so poorly worded.
Did they forget that MS-DOS exists in Windows 98SE or Windows ME?
What about versions of DOS that don't come with Windows, they do know DOS existed before Windows right?
Are they talking about LANMAN and not NTLM so networking in Windows in 9x,3.51,NT4 are unaffected?
Thinking anything <= NT 3.50 would be affected. Don't have my 3.50 VM setup yet (working on it!) so can't verify but I know 3.51 works.

Either a container or a VM running an older Samba version will likely be my preferred solution when SMB1 sunsetting in Samba comes to pass .

Reply 15 of 68, by davidrg

User metadata
Rank Member
Rank
Member

I've done a little bit more testing with Mars-NWE. The following seems to work fine - I could login, get network drives, etc:
MS-DOS 6.22, Windows 3.11, Client32 2.71. VLM Client 1.21 also works fine. The real old NETX client which will work fine on the original IBM PC is also known to work.
Windows 95/98, Client32 3.4c
Windows NT 3.51, Client 4.11b
Windows NT 4.0, Client 4.90 SP2 update D. Gave an error but login completed anyway. An older client might work better.
Windows 2000, Client 4.91 SP5
Windows XP, Client 4.91 SP5 IR2: Login succeeded but then I was forced to activate which no longer works
OS/2 1.3.2, Client 1.3:
OS/2 2.0, Client 2.01: Login gave an error but completed anyway.
OS/2 2.1, Warp 3, Warp 4, Client 2.12

For Windows NT and OS/2 to work I had to adjust section 4 of the Mars-NWE config file to use the same frame types and network numbers as my existing NetWare 3.12 and 4.11 servers. Without doing so the NT and OS/2 clients can't see the Mars-NWE server. Possibly if Mars-NWE was the only NetWare server on the LAN the defaults would have worked fine.

Windows NT 3.50 *should* work but when I tried it saw my existing NetWare 4.11 server and insisted I log into that. Unlike newer clients it seems to have no UI for picking which server or NDS tree to login to. Probably it would have been fine if Mars-NWE was the only NetWare server on the LAN.

There are also clients for RiscOS and Amiga but I don't have the ability to test those. Probably a good chance of them working fine. I also didn't test the NetWare client that comes with windows but it probably works as well as it ever did.

Reply 16 of 68, by Deku_Scrub

User metadata
Rank Newbie
Rank
Newbie

Can this be used with a hot-swap drive bay? Like could I have one drive that holds all of my cartridge-based stuff, unplug that, and then plug in a dedicated PS2, PS3, or X360 drive? That way I don't need more than a couple drive bays, and don't need to buy all of the hard drives at once (my ultimate goal is 6x 14TB drives, but that's a lot to buy all at once, and most desktop cases don't come with that many 3.5" bays these days)

Reply 17 of 68, by elvis

User metadata
Rank Newbie
Rank
Newbie
Deku_Scrub wrote on 2022-02-01, 03:02:

Can this be used with a hot-swap drive bay? Like could I have one drive that holds all of my cartridge-based stuff, unplug that, and then plug in a dedicated PS2, PS3, or X360 drive? That way I don't need more than a couple drive bays, and don't need to buy all of the hard drives at once (my ultimate goal is 6x 14TB drives, but that's a lot to buy all at once, and most desktop cases don't come with that many 3.5" bays these days)

The services expect some sort of sensible top-level directory that is static. So yes it's possible, but you'd have to do some hacking. Options:

1) Ensure any device on /dev/sda1 (or wherever your device is appearing) is always mounted to the same place. Power down, change disks, power back up.

2) Use autofs (aka automount). Have some static top level directory (the tool defaults to /data/retronas, but you can change that. I'll use that as an example). Below that, have automount points, and configure autofs to put them in to places like /data/retronas/cartridges or /data/retronas/consoles or something. Then they can come and go without needing to reboot.

3) Tell RetroNAS to use /media as your top level directory. Many Linux GUIs use /media as their automount location (via tools like udisks or autofs). Mounting and unmounting via the GUI will have the services RetroNAS configures export these as they come and go.

Ultimately RetroNAS is just Linux, and you can do whatever you want with it. Hack it up as you see fit. I assume that people are using it like a NAS with fairly static hard disk setups, and in fact one of it's huge weaknesses is no real ability to modify storage after the fact (unlike a nice commercial NAS where you can do all sorts of weird things to the underlying storage on the fly). I'm hoping Cockpit (GUI system manager) offers some nice tools there, which I need to investigate and do up a nice video on.

But anyhoo, for your scenario, there's some options off the top of my head. Probably some others I haven't thought of. But again, hack away if you need to modify things for your specific use case.

Reply 18 of 68, by BitWrangler

User metadata
Rank l33t++
Rank
l33t++

Frigid legumes... whoops, ahem, Cool Beans....

I could probably figure out something myself but appreciate a no-brainer solution, even if I already got something going, sometimes you want an insta-deploy to try some crap out on the side or something. Sometimes your main hardware goes south and you want a quick fix to fill in while you meddle with it. Sometimes you just want to point a n00b at something you don't have to spend 60 hours explaining.

Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.

Reply 19 of 68, by Deku_Scrub

User metadata
Rank Newbie
Rank
Newbie
elvis wrote on 2022-02-01, 03:53:
The services expect some sort of sensible top-level directory that is static. So yes it's possible, but you'd have to do some […]
Show full quote
Deku_Scrub wrote on 2022-02-01, 03:02:

Can this be used with a hot-swap drive bay? Like could I have one drive that holds all of my cartridge-based stuff, unplug that, and then plug in a dedicated PS2, PS3, or X360 drive? That way I don't need more than a couple drive bays, and don't need to buy all of the hard drives at once (my ultimate goal is 6x 14TB drives, but that's a lot to buy all at once, and most desktop cases don't come with that many 3.5" bays these days)

The services expect some sort of sensible top-level directory that is static. So yes it's possible, but you'd have to do some hacking. Options:

1) Ensure any device on /dev/sda1 (or wherever your device is appearing) is always mounted to the same place. Power down, change disks, power back up.

2) Use autofs (aka automount). Have some static top level directory (the tool defaults to /data/retronas, but you can change that. I'll use that as an example). Below that, have automount points, and configure autofs to put them in to places like /data/retronas/cartridges or /data/retronas/consoles or something. Then they can come and go without needing to reboot.

3) Tell RetroNAS to use /media as your top level directory. Many Linux GUIs use /media as their automount location (via tools like udisks or autofs). Mounting and unmounting via the GUI will have the services RetroNAS configures export these as they come and go.

Ultimately RetroNAS is just Linux, and you can do whatever you want with it. Hack it up as you see fit. I assume that people are using it like a NAS with fairly static hard disk setups, and in fact one of it's huge weaknesses is no real ability to modify storage after the fact (unlike a nice commercial NAS where you can do all sorts of weird things to the underlying storage on the fly). I'm hoping Cockpit (GUI system manager) offers some nice tools there, which I need to investigate and do up a nice video on.

But anyhoo, for your scenario, there's some options off the top of my head. Probably some others I haven't thought of. But again, hack away if you need to modify things for your specific use case.

I'm pretty terrible at using Linux, all of my attempts have gone pretty badly. Maybe it would be better if I had multiple VMs, only one running at a time, and each one is used for a specific hard drive?