NFS Server

The NFS card shares a games folder over NFS version 4.0 for the PS2 clients built on unfs4 by Ronnie Sahlberg — @sahlberg. It is in Desktop and Core from v0.9.3. Edge has no NFS server.

1. PS2 Clients

2. Setting It Up

1. Pick the Games folder. It is shared as export /, so DVD/ and CD/ inside it are /DVD and /CD to the console.
2. Leave Allow writes off unless you need it (see below).
3. Click Start. The card shows the PC's IP.

On the PS2 side there are only two things to enter: the server IP and the export, /. The port is always TCP 2049; the PS2 clients cannot use another, so the card has no port field. There is no user name or password.

Core, from a terminal:

ps2servers serve nfs --root-dir /games
ps2servers serve nfs --root-dir /games --allow-writes

Port 2049 is taken: on Linux the kernel's own NFS server (nfsd) normally holds TCP 2049. The card says so when it cannot bind; stop that service (sudo systemctl stop nfs-server) or serve from another PC. Windows desktop editions have no NFS server of their own, so 2049 is normally free there. Windows Firewall setup adds a rule for TCP 2049.

3. Allow Writes

Off by default. With it off, consoles can list folders and read files, and everything else is refused: nothing in the folder can be created, changed, renamed or deleted, whatever a client sends.

With it on, a client can also create files and folders, write, change a file's size, rename and delete. Each write is on the PC's disk before the console is told it is done, so a PC crash cannot lose a write the console thinks finished; that makes large copies to the PC slower than a copy that is only cached.

• Neutrino's NFS mode is read-only, so its games save to a memory card.
• RiptOPL writes to the export (VMC saves, game settings, Rename and Delete) only while its own NFS Writes row is On. With it Off, RiptOPL only reads, and its games save to the real memory card.
• Launchstation writes when you copy, rename or delete in its file manager.

4. What Is Shared

The same rules as the SMB2/SMB3 server, from one shared implementation:

• Nothing outside the games folder. .. is refused, and a symbolic link that points outside the folder is neither listed nor opened, nor can it be deleted through NFS.
• Names Windows cannot use are not served, on every PC: CON, NUL, COM1 and the other device names, names ending in a dot or space, alternate data streams (file:stream), and the characters <>:"|?*.
• Only files and folders. Devices, sockets and pipes in the folder are skipped.

A filehandle from an earlier run of the server is refused as stale rather than pointing at another file, so a console needs a fresh mount after the server restarts. A connection is never closed for being quiet, because Neutrino connects once each time it loads its NFS modules and cannot reconnect.

5. Limits

• NFS version 4.0 only (RFC 7530). Versions 4.1 and 4.2 are refused, and there is no version 3, MOUNT protocol or portmapper. mount -t nfs from a Linux or macOS PC is not a supported client.
• Credentials are accepted as given (AUTH_SYS or none). There is no Kerberos.
• No locks, delegations or exclusive create. None of the PS2 clients uses them.
• The only attributes served are type, size and modification time, which is all unfs4 asks for.

6. Testing

A CI check downloads unfs4 at a pinned commit, checks it by SHA256, and builds it with the host C compiler and AddressSanitizer: once as Neutrino builds it, reading a game byte-exact, the tail of a 5 GiB file and a missing file; and once with every feature, running unfs4's own test program with writes on and with writes off. RiptOPL's own tests/nfs-live runs its in-game NFS reader against this server (v0.9.3) in RiptOPL's CI, with writes allowed and refused. These prove the client code works against this server on a PC, inside the PS2 builds' buffer limits. They prove nothing about the PS2's own network stack, its timing, or a real console.

Full detail, including what unfs4 needs from a server: docs/NFS.md.