ShareFSServer: bringing RISC OS file sharing into the modern world

Introducing ShareFSServer project, a new tool to make it easy to share files between all versions RISC OS and modern operating systems.

For quite some time I have been working on reverse engineering the Acorn ShareFS and Access protocol, and reimplementing it from scratch in Rust.

The result is ShareFSServer, a new server-side implementation of the original RISC OS peer-to-peer file sharing system. Its goal is simple to describe, but rather difficult to implement correctly: make modern systems such as Linux, Windows, macOS, BSD and NAS devices appear on the network as if they were native RISC OS machines.

In practical terms, this means that a RISC OS machine can see a share from a modern computer through the familiar Discs icon on the icon bar, browse it in the Filer, copy files to and from it, run files from it, and generally treat it like a normal RISC OS ShareFS disc.

ShareFS Discs example when used with ShareFSServer

This is not a new client for RISC OS. That is an important distinction. ShareFSServer runs on the modern machine, while RISC OS continues to use its existing ShareFS client. This means it can work with real machines, emulators, and older RISC OS installations without requiring new software to be installed on the RISC OS side.

Acorn Access was originally Acorn’s peer-to-peer networking system for RISC OS, using TCP/IP protocols to share discs and printers. Originally developed by ANT, in RISC OS 3.10 onwards, Access became part of the operating system. Its main components are Freeway, ShareFS and RemotePrinterSupport. As far as I was able to reverse the whole lot, Freeway handles discovery, ShareFS handles shared filing systems, and RemotePrinterSupport handles printer sharing.

Why ShareFSServer exists

RISC OS has always had a very elegant desktop and filing system model. Remote files can appear naturally in the Filer, and applications can use them through the same FileSwitch interfaces used for local files. FileSwitch is central to RISC OS filing system operation, providing the common services and user-facing behaviour used by all filing systems.

The problem is that the rest of the world has moved on. Today people store files on NAS systems, cloud storage, SFTP servers, SMB shares, NFS exports, Nextcloud, pCloud, remote Unix systems, and many other places. RISC OS machines, especially older ones, cannot reasonably be expected to support all of that directly.

ShareFSServer solves the problem from the other side.

Instead of trying to teach every RISC OS machine every modern protocol, ShareFSServer acts as a protocol bridge. It speaks ShareFS to RISC OS, and speaks modern storage protocols on the host side.

That means an Archimedes with RISC OS 3.10, a Risc PC, RISC OS 5, RISC OS 6, or an emulator (with proper network access) can access modern storage as if it were just another ShareFS disc.

Supported platforms

ShareFSServer is designed to run on a wide range of systems:

  • macOS on Intel and Apple Silicon
  • Linux on x86_64 and ARM64
  • Windows on x86 and x86_64
  • FreeBSD and NetBSD on x86_64
  • NAS platforms where the architecture and operating system allow it

The binaries are intended to be self-contained. On Linux, the project is designed around musl builds, so it does not depend on glibc. The idea is that installation should be as simple as possible: unzip it, edit the sharefs.toml configuration file, and run the server.

Compatibility with RISC OS

The goal is compatibility across the entire RISC OS range, from older Acorn systems through to modern RISC OS 5 machines.

ShareFSServer has been tested with RISC OS 3.x, 4, 5 and 6. The intention is that even very old systems, including machines such as an A310 or an A5000 running RISC OS 3.10, can browse shares backed by modern storage systems.

One of the more fun test results so far has been browsing an SFTP server on the other side of the world from an A5000, with the remote directory appearing on RISC OS as though it were local.

Another interesting test used Jon Abbott’s modified version of CDFake on an Archimedes to play music CDs shared from a media server running ShareFSServer.

What makes this different from OmniClient, MoonFish/SunFish or LanMan98?

There are already ways to move files between RISC OS and other systems. LanMan98, OmniClient, MoonFish/SunFish and some emulators host filing systems all have their place. However, the aging of SMB in LanMan98 and OmniClient and NFS in MoonFish/SunFish (together with some issues running them) and the fact that they do not even run on old systems represent a big problem for the community. Not to mention that the dependency on 3rd party protocols given the relatively small number of skilled software developers in the RISC OS scene has become a serious bottleneck for the user base.

ShareFSServer is different because it is a server-side ShareFS implementation. So

  • First it evolves with RISC OS community needs and does not need to rush to come with protocols developed by way larger teams.
  • Second it can proxy such protocols using the local implementation on modern Operating Systems, so technically any new version of SMB for example already work fine with ShareFSServer without any developer intervention. For example it’s already possible to use SMB 3 + QUIC protocol and proxy it to ALL RISC OS systems as native ShareFS share.

As Rick Murray defined ShareFSServer:

I’m happy with ShareFSserver. I can say “share this” and it just goes and does it.

The RISC OS machine does not need to understand SMB, SFTP, FTP, FTPS, NFS, WebDAV, cloud storage APIs, or anything else. It only needs to do what it already knows how to do: speak ShareFS.

That distinction matters, because it allows very old RISC OS systems to access modern resources without requiring new client-side protocol stacks. This also makes old RISC OS systems more useful and certainly more enjoyable, because ShareFS is already present on many machines, often in ROM, so the extra RAM required on the RISC OS side is minimal.

It also means sensitive information, such as SFTP passwords, FTPS credentials, SSH keys, future vault-backed secrets, shared secrets, or TOTP configuration, can stay on the modern system. RISC OS does not need to store them. This is very important, given that RISC OS has no meaningful way to protect secrets. Without a secure mechanism and place to store shared secrets, any claim of adding client-side security to existing RISC OS systems has to be treated very carefully.

Multi-backend architecture

ShareFSServer offers a multi-backend architecture. This means ShareFSServer is not limited to sharing only local directories.

The project’s direction is to make ShareFSServer a general protocol proxy for RISC OS.

At the moment of writing this presentation, the project supports local shares and experimental native remote backends such as:

  • SFTP
  • FTP
  • FTPS

It can also expose many other protocols through out-of-band local mounts. For example, if the host system mounts SMB, NFS, Nextcloud, ownCloud, pCloud, or another filesystem, ShareFSServer can re-share that mount as a ShareFS disc.

There are two broad ways to proxy a protocol:

Native mode means ShareFSServer understands the remote protocol directly. The connection is configured in sharefs.toml, including credentials or keys where required. This does not require a local cache.

Out-of-band mode means the host operating system, SMB, NFS, FUSE, or another tool creates a local mount point. ShareFSServer then shares that mount point. This is useful when a local cache is desirable, especially for slower internet connections.

The long-term goal is for RISC OS machines to gain access to a much larger world of storage, without the RISC OS side needing to change, and, most of all, having to maintain all these changes.

File types and filenames

One of the hardest parts of this project is not networking. It is filenames.

RISC OS is not Unix, Windows or macOS. RISC OS still has no support for Unicode and has its own pathname syntax, its own file type system, its own metadata conventions, and its own special characters.

FileSwitch treats certain characters as special. For example, . separates directory components, : introduces a drive or filing system specification, * and # are wildcards, $ is the root directory, & is the “user” root directory, @ is the current selected directory, ^ is the parent directory, % is the current library directory, and \ is the previously selected directory.

RISC OS also stores file type information in the load and execution address fields when a file is date-stamped. The top twelve bits of the load address being set indicates a date-stamped file, and the remaining bits contain timestamp and file type information.

This means ShareFSServer cannot simply expose host filenames unchanged and hope for the best. It must preserve RISC OS file type metadata, avoid illegal names, avoid collisions, and still make files usable on the host side.

ShareFSServer therefore supports two filename handling modes:

HostFS mode

HostFS mode behaves in the traditional style used by systems such as RPCEmu HostFS (or, to some extent, by Virtual RiscPC).

For example:

  • A RISC OS file called MyFile with file type &FAF becomes MyFile,FAF on the host.
  • A RISC OS file called MyFile/htm becomes MyFile.htm on the host.
  • A host file called MyFile.html appears to RISC OS as MyFile/html.

This mode is familiar and conservative, but it places more responsibility on the user when moving files between RISC OS and the host.

Advanced mode

Advanced mode is designed for better interoperability between RISC OS and modern locked-down systems (for example Apple iOS devices, or Android devices etc.).

For example:

  • A RISC OS file called MyFile with file type &FAF, when that type is known to map to HTML, can become MyFile.html.
  • A file type with no useful host equivalent becomes MyFile,XXX.
  • A RISC OS file called MyFile/html becomes MyFile,#html.html, preserving both the RISC OS name and the host extension. This particular format helps in two scenarios, first when the extension is non industry standard and a user wants translation to industry standards it preserves the original non-standard extension for RISC OS and then applies the industry standard extension on the host, second if the extension on RISC OS presents mixed upper/lower caps it will preserve those for RISC OS and use always lower caps for the ShareFSServer host.
  • A host file called MyFile.html appears on RISC OS as MyFile with the correct HTML file type.
  • A host file called MyFile,#html.htm appears on RISC OS as MyFile/html and of type html.

This mode is intended to make common file types easier to use from both sides. For example, movies, PDFs, HTML files and text files can be more naturally double-clicked on the host and still retain the correct identity on RISC OS.

Unicode and special characters

Unicode is another unavoidable problem.

Where possible, ShareFSServer translates Unicode characters to a character set RISC OS can understand. Where that is not possible, it must preserve uniqueness. Unsupported characters cannot simply be removed, because two different filenames might collapse into the same RISC OS name.

For example, two filenames that differ only by emoji or another unsupported Unicode character still need to remain distinct. ShareFSServer therefore encodes information where necessary so that filenames do not become ambiguous.

Performance

ShareFSServer is multithreaded and already performs well enough for many practical uses, including browsing directories, opening images, playing audio, and testing video playback.

However, performance testing needs to be done carefully.

Logging should be disabled when testing performance, because logging can significantly affect throughput.

On the RISC OS side, increasing the Next Wimp Slot to at least 4096 KB is recommended for heavier testing. Increasing ShareFSWindow can also help, up to the limits supported by the client.

ShareFSServer also provides configuration options such as:
sharefs_window_size = 4
sharefs_read_ahead_size = 512

The first controls the server-side write window. The second controls how much data the server reads ahead and caches for read operations.

There are still natural limits. ShareFS does not support jumbo frames on the RISC OS side (while ShareFSServer already does). Data chunks are statically capped on RISC OS clients (while they can already be dynamically extended on ShareFSServer). The protocol is UDP-based, but still uses acknowledgements and retransmission behaviour. So it requires a few improvements on the RISC OS side to reach full potential of ShareFSServer.

NAS use

A lot of users have asked about NAS support.

The answer is yes, ShareFSServer is a good fit for NAS systems.

For modern NAS devices, the easiest route will be Docker. The plan is to provide images for common NAS architectures such as x86_64, ARMv7, ARMv8 and, eventually, RISC-V.

For NAS systems without Docker support, the self-contained nature of ShareFSServer helps. Since the binary does not require external runtime dependencies on Linux beyond OS syscalls, it should be possible to install it manually on some NAS systems. That may not be as straightforward as Docker, but it is technically possible where the operating system and CPU architecture are suitable.

A NAS running ShareFSServer can appear to RISC OS as a native ShareFS machine. That means a RISC OS client can browse the NAS through the normal ShareFS user interface.

VPNs and relays

ShareFSServer also includes a relay mechanism that is not part of the original ShareFS protocol.

The relay allows two ShareFSServer instances to communicate across a VPN and rebroadcast shares between networks. This makes it possible to expose shares, directories and printers across sites, CIDRs etc. while still presenting them to RISC OS as ShareFS resources.

This is one of the areas where ShareFSServer is not merely recreating the old behaviour, but carefully extending it in a way that remains compatible with existing RISC OS clients.

Security and authentication

ShareFSServer is designed to enforce the access rules configured on the server side. It also already supports end-to-end encryption, but the old RISC OS client does not.

In other words existing RISC OS ShareFS clients use the original protocol, so ShareFSServer must remain compatible with that behaviour. However, it’s possible to add end-to-end encryption to the RISC OS clients. What is not possible right now is to add security for the required shared secrets, which makes end-to-end encryption on RISC OS very insecure.

Where modern backends are used in ShareFSServer, such as SFTP or FTPS, the connection between ShareFSServer and the remote service can use the security features of those protocols, including post-quantum encryption algorithms. This allows sensitive credentials, SSH keys, certificates, shared secrets, and future vault-backed secrets to remain on the modern host rather than on the RISC OS machine.

I am also working on TOTP support, using authenticator apps such as Google Authenticator or compatible alternatives. The idea is that a protected share can accept a temporary code typed by the user when connecting (from the RISC OS side), without needing to store that changing code on the RISC OS side.

Current development status

At the time of writing this post, ShareFSServer is still alpha-quality software.

That means testers should expect bugs, incomplete features and occasional broken behaviour. It should not yet be used as the only copy of valuable data.

Recent development has focused on:

  • completing Advanced filename mode
  • adding HostFS mode
  • improving SFTP support
  • adding FTP and FTPS support
  • improving large directory copying
  • improving file type handling
  • moving toward zero-copy packet processing
  • expanding automated tests
  • refactoring the multi-backend architecture
  • improving Windows builds
  • preparing for printer sharing work

The project has now passed more than 250 automated test cases, but real machines and real users remain essential. ShareFS behaviour has many details that only become visible when tested against actual RISC OS systems.

Why reverse engineer it?

Because compatibility matters.

The original sources are not available for release as open source with clear written permission. Reimplementing the protocol from observed behaviour, documentation, original binary interfaces and network captures avoids that problem.

The aim is not to copy the old implementation. The aim is to implement the externally visible behaviour required for interoperability.

That is also why the work has taken time. ShareFS is not just a file transfer protocol. It is tied deeply into how RISC OS thinks about filing systems, paths, metadata, file types, directories, access permissions and the desktop.

What comes next?

The current priorities are to continue hardening the file and directory handling, complete the remaining HostFS details, improve remote backends, and resume printer sharing work.

There is also work planned around secrets’ storage, including HashiCorp Vault support, and TOTP-style authentication using apps such as Google Authenticator or similar tools.

Longer term, ShareFSServer should become a practical bridge between RISC OS and a wide range of storage systems: local discs, NAS systems, Unix servers, cloud storage, secure remote protocols, and even historically interesting protocols such as NFS 2 for interoperability with very old Unix systems.

The idea is simple: keep RISC OS usable, connected and enjoyable, without forcing old machines to become something they are not.

ShareFSServer lets RISC OS remain RISC OS, while giving it access to the modern networked world.

Frequently Asked Questions

What does ShareFSServer do?

It makes a Windows, macOS, Linux, BSD or NAS system appear to RISC OS as a ShareFS machine. You can access its shares from RISC OS through the normal ShareFS interface, including the Discs icon on the icon bar.

Do I need to install anything on RISC OS?

No. The point of ShareFSServer is that the RISC OS machine uses its existing ShareFS client.

Do I need to build anything?

No. The intended release model is unzip, configure and run.

Does it require external dependencies?

No. And on Linux, the goal is to provide self-contained musl-based builds with no dependency on glibc either. Other platforms are also intended to be distributed as simple runnable binaries.

Is it complicated to configure?

No. Configuration is done through a commented sharefs.toml file. And for the release date there will be also a web UI that can be accessed and used from all RISC OS browsers from !Iris to !Netsurf to the original Acorn !Browse.

Which platforms are supported?

The project targets macOS, Linux, Windows, FreeBSD, NetBSD and suitable NAS systems, across common x86, x86_64, ARM and ARM64 architectures.

Does it work with old RISC OS machines?

Yes, the aim is compatibility from RISC OS 3.x through to modern RISC OS versions. Testing has included old systems such as A310, A3020, A5000.

Does it work with RPCEmu?

Yes, but RPCEmu networking behaviour depends on the host platform. Bridge mode is generally the safest recommendation. NAT mode can work in some cases, especially on macOS, but bridge mode is usually the simpler answer.

Does it work on Internet?

No, and you should absolutely NOT try use it on the internet. You can use a VPN in between 2 ShareFSServers if, for example, you have one network in a place and another somewhere else.
As I have mentioned, to remain compatible with RISC OS it cannot use encryption (at least yet), and even if it could, RISC OS offers no security to store both shared secrets safely and, more importantly, root certificates safely. So nothing is preventing any application to basically inject a certificate for a fake authority and become able to look into your encrypted connections. A user would not even notice that. So my personal suggestion is:
– Don’t use RISC OS on public networks and WiFi. RISC OS WiFi is very easily confused by rouge hotspots.
– Don’t expose any RISC OS stuff publicly on the internet. It may not get hacked, but only because no one cares, which is not security.

Can I transfer large files?

Yes, large file transfer works in current testing, but there are still RISC OS-side limits to consider.

What is the maximum file size?

It depends on the direction and the filesystem involved.

If copying to a RISC OS FileCore filesystem, the limit is determined by RISC OS and FileCore. For files larger than 4 GB, 32-bit RISC OS clients may need special handling for file size reporting, seeking, copying and Filer display.

If accessing a large file in streaming mode from ShareFSServer, the server side can in theory handle larger files on 64-bit hosts, but the RISC OS client may still impose practical limits.

Can I run executables from a ShareFSServer share?

Yes.

Does it support SFTP?

Yes. SFTP support is experimental but already usable in testing, including browsing remote SFTP shares from old RISC OS machines.

Does it support FTP and FTPS?

Initial FTP and FTPS support has been added.

Why adding an FTP backend if we already have FTP clients?

I am glad you asked 😉

When using an FTP client we usually cannot search on an FTP server, moreover when finding a compressed archive we have to download it first to know if it really is what we need.

With FTP backend on ShareFSServer we can use tools like !Locate to actually search on the FTP server for what we need and we can open archive to check if they truly contain what we are seeking for before downloading them. So yes it can be extremely useful to have FTP and FTPS backend on ShareFSServer.

And finally, let’s remember that with ShareFSServer and all its backends, users can finally write automation scripts and programs (both from CLI or the Desktop) to automate. things using, you’ve guessed FTP, SFTP, FTPS, SMB (all version except for 1), NFS and more as a single API making developers life a lot easier and expanding the possibilities of what we can do with RISC OS.

Can ShareFSServer expose SMB or NFS?

Yes, through out-of-band mounts and later also in Native mode.

Can it be used on a NAS?

Yes. Docker will be the easiest route for many NAS systems, but self-contained binaries may also work on NAS systems without Docker, depending on the platform.

Will my NAS become RISC OS compatible?

In practical terms, yes. It will appear on the network as a ShareFS system, and RISC OS machines will be able to access the configured resources.

How will I operate it on a NAS?

A web management interface is planned, with the goal of being usable from RISC OS browsers such as Acorn !Browse through to newer browsers such as Iris.

Can a NAS share remote resources too?

Yes. Native backends such as SFTP avoid the need for local cache storage. Out-of-band mounts for pretty much every modern protocol is already available and soon will also be available beyond what the host OS can actually do.

Does it work across VPNs?

Yes. ShareFSServer includes a relay protocol that can connect ShareFSServer instances across a VPN and rebroadcast shares between networks.

Do I need to lower Windows security to use ShareFSServer?

No. One of the goals is to avoid the need to weaken Windows file sharing security just to make files available to RISC OS.

Is it fast?

It is already fast enough for many practical uses, but performance should not be treated as final while the protocol implementation is still being hardened. Disable logging when testing speed.

Why do filenames need to change?

Because RISC OS filenames, host filenames and RISC OS file types do not map perfectly onto one another. ShareFSServer must preserve file type metadata, avoid illegal characters, handle Unicode, avoid name collisions and keep files usable on both sides.

Why not simply use names like MyFile/pdf?

That might work on some hosts, but not across Linux, macOS, BSD and other platforms. ShareFSServer needs a portable naming scheme.

Why not store metadata in hidden files?

Hidden metadata files work until a user moves a file outside ShareFSServer’s control. If the metadata is separated from the file, the file type can be lost. Encoding essential metadata into the filename is more robust for cross-platform use.

What is the difference between HostFS mode and Advanced mode?

HostFS mode uses the traditional name,XXX style for RISC OS file types. Advanced mode tries to improve interoperability by mapping known RISC OS file types to useful host extensions where possible.

Does ShareFSServer support Unicode?

Yes. It translates Unicode where possible and preserves uniqueness where direct translation is not possible.

Not only that, but it also support all types of encoding used on the various host platforms where it runs (UTF-8, UTF-16, UTF-8 with rules, raw binary and more).

Can passwords be stored in a secure vault?

That is planned. HashiCorp Vault support is being worked on, and other suggestions are welcome.

Will TOTP authentication be supported?

Yes, TOTP support is planned. The idea is that a protected share can accept a temporary code from an authenticator app, instead of relying only on a static password.

When will printer sharing be available?

Printer sharing is planned to resume once the file sharing side, especially HostFS mode, is solid enough.

Is ShareFSServer production ready?

No. It is still alpha-quality software. It is suitable for testing, feedback and experimentation, not as the only copy of important data.

Why reverse engineer the protocol?

Because the original sources cannot currently be released with clear written permission. Reimplementing the protocol from documented behaviour, source interfaces and network captures is the clean route to compatibility.

What is the long-term goal?

The long-term goal is to make ShareFSServer a modern protocol proxy for RISC OS, allowing old and new RISC OS systems to access local filesystems, NAS storage, cloud storage, secure remote protocols and other network resources through the familiar ShareFS interface.