9. Network and remote access
The server's network
Settings > Network has the tabs General, Interfaces, Routes, Wi-Fi, VPN Client, Speed Limits, Wake-on-LAN and Proxy.
The server's network cards are in a bridge, so virtual machines and apps with an address of their own sit on your network like any other device.
- General: the server's name, the DNS servers, Answer as name.local (the server's name followed by
.localon your network), and Addresses for apps: a range of your network's addresses that apps may take, so their ports never collide. Keep that range out of your router's DHCP range. - Interfaces: an automatic (DHCP) or fixed address for each interface, several network cards, bonds (LACP, active-backup, adaptive load balancing), VLANs, a card with an address of its own or none, and IPv6 (automatic, DHCPv6 or fixed) for each.
- Routes: static routes to other networks.
- Wi-Fi: join a WPA2 or WPA3 network. A network cable, when plugged in, is used first.
A change that cuts you off is undone. When a change might cut your browser off (a new address, a bond), OSM waits for you to confirm from the new address; with no confirmation within 90 seconds, the server goes back to the old settings by itself, even across a restart.
Speed limits, Wake-on-LAN and a proxy
- Speed Limits: limit the speed of a service (SMB, NFS, FTP, the web desktop, backup and rsync, or the container apps together) or of one account over SMB, at all times or at chosen hours. Backup and rsync is rsync on port 873, to the server and from it: OSM's own backup, cloud and replication tasks are not limited by it.
- Wake-on-LAN: whether this server may be woken by a magic packet (the computer's firmware must allow it too), and waking other computers of your network by their MAC address.
- Proxy: when the server may reach the Internet only through a proxy: updates, container images, backups and certificates go through it.
VPN: reaching home from anywhere
Install VPN from the App Catalog: a WireGuard server for your phones and laptops.
- Add a device: a QR code for the WireGuard app on a phone, or a file for a computer. It is shown once only: the device's private key is not kept on the server.
- Choose what the devices reach: This server only, This server and the LAN, or Everything (all their Internet traffic goes through home).
- Your router must forward the VPN's UDP port to the server (Settings > Internet Access > Router can ask it to), and the devices need an address to connect to: your Dynamic DNS name, or your public address.
The VPN is safer than forwarding the web desktop's port: only the VPN's port faces the Internet, not OSM itself.
VPN client: the server through another VPN
Settings > Network > VPN Client connects the server to a WireGuard or OpenVPN network: for the VPN's own networks only, for the apps you choose, or for everything of the server (your local network stays reachable). A kill switch blocks what would otherwise leave without the VPN while it is down. A profile's own commands never run: a WireGuard file that has them is refused, and an OpenVPN file's are left out (OSM shows which lines).
OSM Connect: the server from anywhere
Settings > OSM Connect gives the server an address of its own on the Internet, like https://n4bq7x2m....eh7ddx5b.osm-relay.com/, through OSM's relay: nothing to open on your router, no address to know. The connection is encrypted from your browser to the server; the relay passes it on without being able to read it. It needs an OSM account with OSM Connect, and two-step sign-in with an authenticator app for your own account (My Account > Security).
Turning it on, on the server's own network:
- Click Turn on.... The first time, the server installs the program for the tunnel (a minute).
- The page shows a pair code. Click Open the OSM account site, sign in to your OSM account and confirm the server with that code. The site also shows the last four characters of the server's ID: check that they are the ones on the page.
- The server sets up its address and gets its certificate by itself. This takes a few minutes; you can close the window. When it is done, the page shows On, the address, and Reached from outside: the server opened its own address from the Internet and found itself.
Signing in through OSM Connect is stricter than at home:
- Only Administrators may sign in, unless you choose more under Who may sign in (Administrators and chosen groups, or every account). Each one needs two-step sign-in or a passkey: a password alone never signs in there, and no browser is trusted.
- A sign-in ends after 30 minutes without use, and after 12 hours in any case.
- Deleting data, changes to accounts, passwords or security, network and update settings, and every change to the domain (Domain) ask for your code again (Confirm it is you).
- 20 failed sign-ins within an hour pause sign-ins through OSM Connect for an hour. The Administrators are told; those signed in already go on, and signing in at home works.
- A sign-in from a new browser or place is told to the Administrators (bell and email) and to the account's email address.
- Off unless you turn them on: The terminal (and containers' terminals and virtual machines' screens), Public share links, API tokens (a token must also be made with It may also be used through OSM Connect).
- Apps' own pages, password reset by email and the installer are not reachable through OSM Connect. These rules are changed on the server's own network only.
A sign-in at home and one through OSM Connect are separate: each works only at its own address.
Keep the address to yourself: it is how the server is found. New address... gives the server another one at once and the old one stops working (bookmarks too). Show this server's address in my OSM account (on unless you turn it off) lists the address on the account site, so you can open the server there with Open; the site keeps it encrypted. Turned off, the account site lists the server without its address.
Turn off stops the tunnel and the address at once; the server stays linked to your OSM account, so turning it on again is quick. Turn off and unlink... also removes the server from your OSM account.
If OSM moves OSM Connect to a new domain (it keeps a spare one ready, in case osm-relay.com can no longer be used), the change comes with an OSM update. The server keeps its address until its new one is ready (the page says OSM Connect moves to a new domain meanwhile), then switches by itself and tells the Administrators. Then:
- open the new address from your OSM account (Open) or from Settings > OSM Connect, and update your bookmarks;
- install the phone app again from the new address;
- make passkeys for OSM Connect again: until you do, sign in with your authenticator app's code.
On a busy week the new address can take a few days to come; the old one works until then.
When it stops by itself, the page says why and the Administrators are told: the server was removed from the OSM account, OSM blocked OSM Connect for it, this version of OSM is too old for it (update OSM), or a certificate for its address was made somewhere else (the server watches the public certificate logs every day; contact OSM's support). Click OK, then turn it on again when you are ready.
What OSM's relay sees: which server is visited, from which address, when, and how much; never what you do there.
Reaching the server from the Internet
Settings > Internet Access:
- Remote access: reach the server from anywhere without opening a port on your router, through Tailscale (or a Headscale server of your own). Optionally the server shares your local network with your other Tailscale devices, or is their exit node. A relay server of your own, in the same tab, uses a small server on the Internet (a VPS) instead: it forwards the ports you choose to this server through a WireGuard tunnel that this server opens. What you forward is open to the whole Internet.
- Dynamic DNS: a name that follows your home's public address (DuckDNS, deSEC, No-IP, Dynu, FreeDNS, Cloudflare, or any dyndns2 service), updated when the address changes.
- Router: ask your router (UPnP) to forward ports to the server, renewed every half hour. Forward only what you need.
- Apps' addresses: below.
An address for each app
Settings > Internet Access > Apps' addresses gives an app an address of its own, served by the server with its certificate:
- a name:
https://photos.example.com(the name must lead to your server, through your DNS or Dynamic DNS, and be in the server's certificate), or - a path:
https://nas.local/photos.
The apps' addresses are served on a port of their own (HTTPS port for apps, 443 by default), never on the web desktop's, so no app shares the web desktop's origin (and its sign-in).
Certificates
Settings > Security > Certificate:
- Self-signed: made at the first start. Browsers warn about it until you trust it on each device. The tab shows the certificate's SHA-256 fingerprint: compare it with the one your browser shows before you trust it.
- Import... a certificate of your own (with its private key).
- Let's Encrypt: a free, trusted certificate for names of yours on the Internet, renewed by itself a month before it ends. The HTTP challenge needs port 80 forwarded to the server; the DNS challenge works without any open port, with the API of your DNS provider (18 providers are supported), and also gives wildcard certificates (
*.example.com).
Network Boot: computers that start from the server
Network Boot (from the App Catalog) lets the computers of your network start from the server, without a USB stick: an installer or a live system from a menu, or a disk of their own on the server. Your router keeps giving the computers their addresses; OSM only tells them where to start.
Turn it on in Network Boot > Settings: choose the Network the computers are on, switch it On and choose Save. The server then answers there alone: ports 67, 69 and 4011 (UDP) for the computers' firmware, and port 5069 (TCP) for the menu. Also choose:
- Who gets an answer: every computer that asks, or only the computers on the list (Computers).
- Menu wait: how many seconds the menu waits before it starts its default (0: the default at once, no menu).
- Default: what the menu starts when nobody chooses: the computer's own disk, or one of the boot images.
On each computer, before it starts from the network:
- In its firmware (the BIOS or UEFI setup), put the network (PXE, or "network boot") first among the ways it starts. The menu's first entry goes on from the computer's own disk, so nothing changes for it unless someone chooses.
- Turn Secure Boot off: the program that shows OSM's menu (iPXE) is not signed for Secure Boot.
- Make sure nothing else on your network answers it the same way (another PXE server, or a router set to send computers elsewhere).
- A virtual machine with UEFI firmware needs a random number generator device (virtio-rng): without one, recent UEFI firmware offers no network boot at all. Virtual machines of OSM's own have one.
Boot images. In Network Boot > Boot menu, choose Add an ISO... and pick an ISO file from a shared folder. OSM copies it to the volume of the boot images (set in Settings) and takes out what starts it from the network; the job shows how far it is. OSM starts:
- Ubuntu and systems made like it: the whole ISO is loaded into the computer's memory, so it needs more memory than the ISO's size.
- Debian live systems, and Debian's network installer (the
mini.isoof Debian's "netboot" folder). - Fedora live systems and installers, and Red Hat's and related installers.
- OSM's own installer.
Windows installers and Debian's installer DVDs do not start from the network yet: use a USB stick for those. Edit... changes an image's name in the menu and what its system takes at its start (like console=ttyS0); the arrows change its place in the menu.
Computers. Network Boot > Computers lists the computers OSM knows, by their network card's address (MAC). Computers that asked lately shows the ones that started from the network: choose Add... to put one on the list. For each computer on the list, choose what it starts: the menu, its own disk, or one boot image.
A disk on the server (install iSCSI Storage first). In the computer's menu (···), Give it a disk on this server... makes it a disk that only this computer may use, with a password of its own (a LUN of iSCSI Storage called nb- and the computer's name; change it here, not in Storage > iSCSI):
- New and empty: the computer then starts the menu with its new disk attached, first in the menu. Choose an installer from the menu and install the system on that disk; from then on the menu starts it by default.
- A copy of a master: made at once (the master and its copies need a Btrfs volume). With Made new from the master at each start, everything written to it is gone at the computer's next start: it always starts as the master is, which suits classrooms and shared computers.
A disk is never changed while a computer uses it: a computer that restarts waits a few seconds until its last start has let go of its disk. Make its disk new from its master does it at once while the computer is off.
Masters. A master is a frozen copy of a disk, which the computers' disks are copies of. Give one computer a new disk and install and set up its system; shut it down; in Network Boot > Masters choose Publish a master... and pick its disk. Then give the other computers a copy of it. Publish again... takes the disk as it is now: copies made new at each start take it at their next start, the others when they are made new.
What to know about safety. Network Boot trusts your network: a computer is known by its network card's address, which another device on the network can copy, and what the computers' firmware fetches is not encrypted (no firmware can check a certificate of OSM's). OSM gives a disk's password only to the network card it belongs to, and never while someone is logged in to that disk. Still, keep computers whose disks hold something to protect on a network of their own (a separate network or VLAN), and turn Network Boot off when you do not use it.
Other network services
- Time server for your network: Settings > Language and Time lets other devices take the time from the server (NTP).
- SSH: Settings > SSH (install SSH server first): the port, and whether passwords are allowed or only keys. Administrators can use sudo; root cannot sign in over SSH.
- The firewall decides who reaches all of this: see Security.