Build and Configure Samba Server (from scratch) to share resource with RISC OS 4,6 and 5

To everyone interested,
I have finally managed to have some time (last night) to finish this blog article that explains how to build and configure a Samba Server on Linux (on a Raspberry Pi or any other hardware) from scratch, to share resources with RISC OS 4,6 and 5.

So, while we wait for a proper LanMan98 upgrade to latest SMB releases, or if we want to share resources with our retro RISC OS devices, we’ll no longer have issues with latest Linux/Samba releases.

The article also contains information to install and configure extra bits of software to ensure your Samba Server is easily seen by your latest Mac and Windows machines (and NO need to lower Windows 10 or 11 security by enabling SMB1 anymore).

https://paolozaino.wordpress.com/2023/03/07/retrocomputing-how-to-build-a-raspberry-pi-server-to-share-files-with-retro-or-vintage-systems-and-modern-platforms-part-1/

Hope this helps and have fun! :)

P.S. (1) this article is complementary to this video that explains how to use Git on Linux FROM RISC OS (via !Nettle) for anyone interested in using git in a secure way with their RISC OS coding activities

https://www.youtube.com/watch?v=qN5LW6hG7Rk

P.S. (2) It “should” work with RISC OS 3 as well using !LanMan98, but I had no time yet to test! Sorry.

I was hoping that no one would do that, so developer effort would be put in to updating SMBv1 clients, rather than allowing a horribly insecure protocol to persist.

So thanks for now, but SMBv1 needs to die yesterday.

I was hoping that no one would do that, so developer effort would be put in to updating SMBv1 clients, rather than allowing a horribly insecure protocol to persist.

I understand your point, I do, but you’re obviously aware that people are enabling SMB1 on their Windows systems to share files with RISC OS right now, right? Now, that is extremely dangerous (especially because they more likely use their Windows systems for home banking, private data and whatnot).

The approach in the article solves that problem and make sure people NO longer need to enable SMB1 on Widnows 8/10/11 (or use NETBIOS for name resolution on Windows) where actual malware exists to exploit SMB1.

With that said, I totally agree with you that SMB1 should go ASAP, but so should old NFS releases too and quite a lot more bits. Also there is always the issue for Retrocomputing users that they will still have old RISC OS systems, but that is another story.

Anyway, thanks for your feedback :)

I absolutely agree that SMB v1 must vanish – it is a real pain in the A to have to enable it on Windows, MacOS, or on my NAS.

The solution with some dedicated Linux box – be it a PI or some linux on your NAS – ist certainly a nice idea but is simply a pain in the A since it would imply me having to copy files twice to transfer from one to the other system – that is not an option I care to use to share files between different OSses since I do use Windows and RISC OS in regular exchange between the two.
For simply sharing across RISC OS machines I can use a much more secure approach (albeit security by obscurity) called ShareFS so that for this purpose using LanManFS/98 and some SMB share is just a waste of additional hardware and work.

… or rely on NFS with MoonFish/SunFish, or use some USB-Key, …

I absolutely agree that SMB v1 must vanish

Indeed. Replacing insecure SMB1 on Windows with insecure SMB1 on Linux doesn’t seem to me to be much of an improvement, and adds an extra step in moving files between RISC OS and Windows. However I’m sure it will be useful information for anyone already using Linux.

All, thanks for your feedback :)

For simply sharing across RISC OS machines I can use a much more secure approach (albeit security by obscurity) called ShareFS

I wish ShareFS would be stable so that the statement you’ve made would be true, but in reality ShareFS isn’t that stable and certainly it isn’t suitable for people who wish to code on RISC OS and use git in a secure way (as shown in the video).

Moreover, having a code repository shared via SMB or NFS is particoularly useful when someone needs to test code on multiple RISC OS’s boards, ’cause one build is immadiately shared across all RISC OS based systems.

or rely on NFS with MoonFish/SunFish

Probably the best solution would be to complete the support for NFS 4 on MoonFish/SunFish, but this is another story.

Replacing insecure SMB1 on Windows with insecure SMB1 on Linux doesn’t seem to me to be much of an improvement, …

It does improve the security posture of a Windows System for which actual malware and attack techniques exist for ALL SMB versions. Not to mention that more and more often Windows computers are laptops these days with a high risk of being used in a cafe or at an airport WiFi where you certainly do not wish to have SMB1 (but also SMB2 and SMB3) enabled, right? :)

Also, just to be clear, vulnerabilities like SMBGhost or SMBBleed were found on SMB 3.1.1 (the latest version of the protocol). So, if security is a concern, then my recomendation would be NOT to use SMB at all. Also please note that NTLM based attacks works across multiple version of SMB too, so, to kinda make SMB “secure” one should also ensure to implement Kerberos protocol in their own network and there is more.

The advantage of moving certain aspects on a Linux box is that, for example, Samba can be executed in chroot on Linux, it can be easly firewalled and, also the Pi, can use an host based IDS (intrusion detection system), many are available for free. This will enormously reduce the attack surface and ensure that a Windows Laptop doesn’t require to have SMB1 or even SMB2 enabled).

… and adds an extra step in moving files between RISC OS and Windows

It adds an extra step if you just need to share one file between one Windows machine and one RISC OS machine, while it reduces steps when someone needs to build software and quickly test it on multiple RISC OS system :)

[edit]
Also, another useful bit is that on Linux one can disable the execution bits and even implement security policies via SELinux for Samba. Given that there seems to be some (albeith confusing) secuirty related comments, I thought it would be useful to mention.
[/edit]

Apropos of very little, I have found Access (ShareFS/Freeway) to be very useful at connecting PCs in a large LAN that, thanks to Active Directory and (presumably) security/domain settings, couldn’t connect any other way.

Freeway was Bonjour a decade before before Bonjour.

Freeway was Bonjour a decade before before Bonjour

Given the network jibber-jabber that is Bonjour¹, that’s either a nasty thing to say about Freeway, or a load of unwarranted baggage in Bonjour.

¹ The standing instructions on network printer setup list many items to disable, IPX² and Bonjour are up top.
fn2. Nasty, nasty, but it could get through routers, so penning into a small corner was easy :)

in reality ShareFS isn’t that stable

I have never really had problems with ShareFS except with it locking up when copying files if one of the machines is significantly faster than another. That can be fixed by doing

ShareFSWindow 1 { > null: }

We have that executed in the boot sequence.

I find ShareFS very useful if one machine is doing a processor-intensive task and you want to look (remotely) at some of the stuff it has processed whilst it is still busy.

I used ShareFS in a large network of users from 1994 to 2004, and personally ever since and can’t remember ever having a problem.

I used ShareFS in a large network of users from 1994 to 2004, and personally ever since and can’t remember ever having a problem.

All one large subnet? Define large.

No, multiple subnets.

I patched Freeway to enable its partially-implemented remote network support (which I think was related to Econet and otherwise unusable, certainly at the time):

Ah, unicast not broadcast then

If you say so. I know precisely nothing worth mentioning about networking.

I know precisely nothing worth mentioning about networking

I think I can say the same about at least half of the stuff you seem to know. I think you’re winning.

Interesting read. I had a similar problem a while back with a Turtle Beach Audiotron (a hi-fi sized music streamer). The Audiotron only supported LMv1 authentication. Unfortunately that meant (at that time) I had to drop the security level on Samba down to LanManv1.

I’ve solved the problem now. All the media is stored on a separate server, which isn’t exposed to the public internet. The various media shares on this are set to “guest ok” and “read only”. (There’s a separate share which is writeable and needs authentication.) The Audiotron can connect to \\media\music without throwing any errors.

Of course it’s academic as I migrated everything over to Squeezebox which is much more flexible (and doesn’t require remote access to the file system), but it’s interesting to note that others are having similar problems with ‘legacy’ kit.

I have seen an experimental partial SMB2/3 client for RISC OS. I’m not going to name the author, in case he doesn’t want it to be known. He can pipe up if he wishes. But an SMB2 and SMB3 client has been shown to work on RISC OS.

@ Glenn

I had a similar problem a while back

Indeed, and yes the article and procedure is for many retro systems, included old clients for Amiga OS, IBM OS/2, MS-DOS, Widnows 95,98 etc. and old devices.

@ Dave

I have seen an experimental partial SMB2/3 client for RISC OS.

If you’re refering to the client that uses a port of LibSMB2, that is RISC OS 5 only and via “UnixLib” (or whatever it’s called these days), so not an SMB3 module (or better plugin for !OmniClient or new release of !LanMan98).

With that said, yes it’s an improvement that can help on specific scenarios, but to cover all uses we’ll need a client that integrates with the Filer as it happens for OmniClient for example.

But sure it’s a step forward indeed :)

He’s refering to my module I have a demo here SmbFS_demo.

It works with Omniclient. All it does is connect and give a directory display. It should connect to an SMB 3 server and connects with windows for me.

I got bogged down with the unicode to current acorn alphabet conversion – seems more like an art than a science – so stopped there.

I got bogged down with the unicode to current acorn alphabet conversion – seems more like an art than a science – so stopped there.

I’ve not tried this, but I think the method is…

Issue service call 0, &43, 8, .
If R1 is zero, the call was claimed and R4 will be a pointer to as UCS table.

SYS "OS_ServiceCall",, &43, 8, 101 TO ,c%,,,t%

If c% is 0, then t% points at a table of 256 words. Each word corresponds to the UCS code for that character in the specified RISC OS character set.

So, if t% is a pointer to the table, and 140 is the code for “…”, then…

>c% = t%!(140<<2)

>PRINT c%

      8230

>

For your use, you’re going the other way, so for characters that are above 255 (standard ASCII is the same, and the standard accented characters pretty much match as far as I can see), then you’ll need to scan the table looking to see if there’s a match. If there isn’t, then you’ll need to set the character to some sort of dummy value like “_” (can’t use “?” in filenames) because there’s no direct match. Let’s just hope the user isn’t enumerating files in a non-Latin character set. ;)

It already does the basic conversion converting unknown characters to `xxxx format – I can’t remember the details its been years since I looked.

I would expect that our most competent local expert on character sets is nemo. He’s busy at the moment (probably preparing hard for a very interesting presentation to ROUGOL on Monday), but perhaps he will have something useful to say when he has recovered.

For your use, you’re going the other way

Operation in both directions is necessary.

Rick, do you store files with Japanese filenames on an SMB server? How would you expect them to be rendered on RISC OS at the moment? (This is a naive question, not a challenge in any way.)