Your file server, on the box that already runs your mail.
Drive turns your OxiMail into the file server of the office. On the local network it mounts as an ordinary network drive over SMB, so Windows, macOS and Linux see it without installing anything. The same files open in the browser from anywhere, carry their own version history, and can be shared by a link your server issues. Your documents stay files, edited in the applications you already own — we are not rebuilding Google Docs.
Three arguments. One product.
One box instead of two
The NAS in the cupboard is a second machine to patch, back up and worry about, with its own accounts and its own firmware end-of-life. Drive puts the files on the server that already holds the mail, the calendar and the contacts — same backup, same encryption at rest, same update.
Files stay files
Drive is a file server, not a document suite. Your team keeps LibreOffice, Word or whatever it already uses, opens documents from a drive letter, and saves them back. That is a deliberate choice: sovereignty is worth little if the only way to open your own document is a web editor someone else operates.
One identity instead of four
No more matrix of AD account, mail account, VPN account and NAS credential. One OxiMail account, one authentication surface, one revocation path when someone leaves. LDAP sync is there for enterprises that keep an AD of record — but AD stops being the authentication boundary.
The NAS you have today vs Drive.
Six dimensions where the difference is structural rather than a matter of tuning. The point is not that SMB is bad — Drive speaks it too, and it is the reason nothing needs installing on the workstations. The point is what sits behind the share.
| Dimension | A separate NAS / Samba box | OxiMail Drive |
|---|---|---|
| Machines to operate | A second appliance with its own firmware, patch cycle and end-of-life | The server that already runs your mail — one backup, one update |
| On the office network | SMB share | SMB share — nothing to install on the workstations |
| Away from the office | VPN, or files emailed to yourself | The same files in the browser over TLS, and the Sync agent on laptops |
| Versions and deletions | Snapshots, if someone configured them | Per-file version history and a trash, built in |
| Sharing outside the company | An attachment, or a third-party service nobody approved | A share link your own server issues, and can revoke |
| Identity management | AD + mail + VPN + NAS — separate systems to keep in sync | One JMAP identity, LDAP sync available |
SMB on the LAN, JMAP everywhere else.
The SMB service is served by OxiMail itself and is deliberately bound to the local network: file shares are a poor thing to expose to the internet, and every serious incident of the last decade agrees. Changes made from a workstation appear immediately elsewhere, because the SMB layer is wired to the same event bus as the rest of the server rather than polling a directory.
Off the LAN, the same tree is reachable over JMAP: the browser client, and the Sync agent that mirrors a folder to a laptop with an offline queue and conflict resolution. Files carry versions, a trash, and share links whose tokens are issued once and can be revoked. Access follows the OxiMail sharing model: principals, per-folder entries, inheritance, LDAP-synced groups.
What is not there yet: the native mount from outside.
Today, working away from the office means the browser or the Sync agent. What is still in development is the native mount over HTTPS on port 443 — a drive letter that behaves the same on the office network and from a hotel, with no tunnel and no port 445 anywhere.
That is the piece that would let a VPN disappear entirely for file access. We are not putting a date on it: this page will say it is available on the day it is, and not before.
Tell us about your file server.
Replacing a file server is a migration, not an install: existing shares, permissions inherited from years of history, workstations that must not notice anything on Monday morning. We would rather look at yours before you commit to anything.
Tell us how many users, which operating systems, and where the files live today. We will tell you plainly whether Drive fits as it stands, or whether you should wait for the native remote mount.