Create Samba (SMB/CIFS) and NFS Shares on OpenMediaVault

One OpenMediaVault folder, shared over SMB and NFS at once, read back at 118 MB/s through both protocols. That is the wire limit of our gigabit test link, so the protocol choice did not change the speed. What broke on the first try was permissions: a read-only SMB user, an NFS client whose UID meant nothing to the NAS, and a folder an admin had created over SSH all returned “Permission denied” for three different reasons.

Original content from computingforgeeks.com - post 116352

This guide builds an OpenMediaVault SMB share and an NFS export of the same folder from an empty data disk. It then mounts both on a Linux client with mount -t cifs, mount -t nfs4 and fstab entries that survive a reboot. Every screen was captured from the openmediavault workbench on a Debian 13 VM, every mount was run from an Ubuntu 26.04 client, and each permission error below is one we hit and fixed on that pair. A Windows client was not part of this run.

Tested October 2026 on openmediavault 8.5.11 (Debian 13).

SMB vs NFS on OpenMediaVault: measured throughput

Both protocols saturate a gigabit link for reads, and both writes stop at the speed the client can push towards the NAS. The table holds three runs per protocol against the same media folder on an ext4 data disk.

Test	SMB (vers=3.1.1)	NFS (vers=4.2)
Sequential write, 1 GiB, 3 runs	96 / 76 / 92 MB/s	93 / 71 / 80 MB/s
Write mean	88 MB/s	81 MB/s
Sequential read, 1 GiB, 3 runs	118 / 118 / 118 MB/s	118 / 118 / 118 MB/s
iperf3, client to NAS	777 Mbit/s (about 97 MB/s)
iperf3, NAS to client	945 Mbit/s (about 118 MB/s)

Here is how each number was taken:

• Write: dd if=/dev/zero bs=1M count=1024 conv=fsync into the mounted share, so the timer stops only after the NAS confirms the data is on disk, not when the client page cache fills.
• Read: the same 1 GiB file read back to /dev/null after sync; echo 3 | sudo tee /proc/sys/vm/drop_caches on the NAS and the same drop on the client, so neither side could serve the file from RAM.
• Link baseline: 10 second iperf3 runs between the two VMs, which sit on different Proxmox nodes joined by a gigabit switch. A plain iperf3 -c from the client measures client to NAS (777 Mbit/s, 780 on a later rerun), and iperf3 -c -R reverses it to NAS to client (945, then 941).

The reads land exactly on the 945 Mbit/s the link carries towards the client, so on gigabit the disk and the protocol are not the bottleneck. The writes track the slower 777 Mbit/s direction, and the spread between runs (71 to 96 MB/s) is larger than the gap between SMB and NFS, which puts the protocols within the margin. Pick the protocol by client, not by speed: SMB for Windows, macOS and mixed households, NFS for Linux hosts, hypervisors and containers that need real POSIX ownership. Serving both from one folder, as this guide does, costs nothing measurable.

Prerequisites

You need a running openmediavault server and one empty disk for data, because openmediavault will not create shares on its own system disk. If the server is not installed yet, our OpenMediaVault installation guide covers it. The lab used:

• NAS: nas01 at 10.0.1.50, Debian 13 with openmediavault from the official synchrony repository, 2 vCPU and 2 GB RAM, a 20 GB system disk (/dev/sda) and an empty 20 GB data disk (/dev/sdb).
• Client: client01 at 10.0.1.51, Ubuntu 26.04 with cifs-utils, nfs-common and smbclient.
• Access: the workbench admin login (admin, default password openmediavault, which you should change on first login) and SSH to the NAS for the two verification commands.

That VM spec is a floor for following along, not a production recommendation. File serving needs little CPU, so size a real NAS by its disks. Plan usable capacity for the data plus 20 to 30 percent free space, and a redundancy layout you can rebuild from (our RAID vs LVM vs ZFS comparison covers the trade-offs). Then add enough RAM for the page cache to hold the files people open most.

The data disk is the part worth spending on, because every share in this guide lives on it and a desktop drive that parks its heads every few seconds will wear out under constant small reads. Drives built for 24/7 duty matter more than any setting in this guide, and the NAS hard drives we recommend are the ones we would put behind these shares.

One lockout warning before you touch SSH on a NAS you installed on top of Debian. openmediavault rewrites sshd_config with AllowGroups root _ssh, so the user you created in the Debian installer can no longer log in. Our first connection after the install failed with Permission denied (publickey,password). Add that user to _ssh from a session that is still open (or from the console), or tick the _ssh group for it under Users in the workbench. Replace klinsmann with the username you created in the Debian installer:

sudo usermod -aG _ssh klinsmann

Group membership is read at login, so the change only applies to new sessions. Open a second SSH session to confirm it works before you close the one you are in. The same rewrite sets AllowTcpForwarding no, so an ssh -L tunnel to the workbench gets nothing back. The switch for it is the TCP forwarding checkbox (“Permit to do SSH tunneling”) under Services > SSH. We left it off and opened the workbench over the LAN at http://10.0.1.50/ instead.

Step 1: Set the NAS address on the client

The NAS address appears in every mount command on the client, so set it once as a shell variable. Replace the value with your NAS IP, which the workbench shows under Network > Interfaces:

export HOST_IP="10.0.1.50"
echo "NAS: ${HOST_IP}"

The variable lives only in the current shell. If you reconnect to the client later, run the export line again before the mount steps, or the commands will try to reach an empty host name.

Step 2: Create a file system on the data disk

Shares live in shared folders, and shared folders live on a mounted openmediavault file system, so the empty disk comes first. Storage > Disks lists every block device the kernel sees. On our VM that was the system disk, the 20 GiB data disk /dev/sdb, and a 4 MiB /dev/sr0 that is the cloud-init seed ISO.

Go to Storage > File Systems, click the + (Create and mount a file system) button and choose EXT4. The device list only offers disks with no partitions or signatures, which is why a disk that once held a ZFS pool or a RAID member stays hidden until you wipe it under Storage > Disks. Select the data disk and click Save.

The workbench runs sgdisk and mke2fs in a log window and finishes with “END OF LINE”. On the 20 GiB disk it wrote one GPT partition and an ext4 file system of 5242619 4k blocks with 1310720 inodes. Close the window and the file system exists, but it is not mounted yet and does not appear in the list.

Click the play icon (Mount an existing file system) and pick /dev/sdb1 [EXT4, 19.99 GiB] from the list. Read the entry before you save: on our VM the first entry was /dev/sr0 [ISO9660, 4.00 MiB], and our first attempt mounted the cloud-init ISO instead of the data disk. The yellow banner’s Undo button reverted it cleanly. Once the right device is saved, the banner asks you to apply the change.

Every form in this guide works the same way: Save only writes the openmediavault database, and nothing touches the system until you click the check mark on that banner and confirm. After the apply finished, the row showed 19.50 GiB available, a tick under Mounted and the status Available. The file system is mounted under /srv/dev-disk-by-uuid-<uuid>/, which is the path the shared folder will point into.

Step 3: Create the users that will log in to the shares

SMB needs a username and password per person, and openmediavault only sets the Samba password when you set the account password in the workbench, so create share users there rather than with adduser over SSH. We made two accounts to test both privilege levels: nasuser gets read/write and viewer gets read-only. Go to Users > Users, click + then Create, and fill in the name and password. The examples in this guide show ChangeMe-Example1 as a stand-in, so set a real password of your own here and use it wherever that string appears.

Leave Groups empty. openmediavault puts every new account in the users group (GID 100), and that group membership is what lets the account write into a shared folder with the default mode. After Apply, id on the NAS showed uid=1001(nasuser) gid=100(users) and uid=1002(viewer) gid=100(users). Note the 1001: it comes back in the NFS step, where the NAS has to map a client’s UID to an account it knows.

Step 4: Create the shared folder and set privileges

A shared folder is a directory on the data file system that the SMB and NFS services can both export. Go to Storage > Shared Folders, click +, name it media, select the ext4 file system and keep the default permissions, “Administrator: read/write, Users: read/write, Others: read-only”.

That default produced drwxrwsr-x root users on disk: mode 2775, owned by root, group users, with the setgid bit so new files inherit the group. Any account in users can write there at the file system level, and everyone else can only read.

Now select the media row and click the Permissions button. This page decides who the SMB service lets in, and the blue note at the top is the most misread sentence in openmediavault: these settings have no effect on file system permissions. Set nasuser to Read/Write and viewer to Read-only, then Save and Apply.

Keep the two layers apart, because every “Permission denied” in this guide came from mixing them up. A user needs both to write, and each protocol reads them differently:

• Share privileges (this page): openmediavault turns them into Samba’s valid users, read list and write list, so they apply to SMB and to any other openmediavault service that logs users in to a shared folder. NFS ignores them.
• File system mode and ACL: the owner, group and mode of the directory, edited on the Access control list page, decide what the kernel allows once a request reaches the disk.
• NFS: works only from the file system layer plus the export options, because it has no login to check a privilege against.

So a Read/Write privilege on a directory the user cannot write to still fails, and the fix for that is never on this page. The troubleshooting section at the end walks through exactly that case.

Step 5: Enable SMB/CIFS and create the OpenMediaVault SMB share

The SMB service is off after install, and a share created while it is off is saved but never served. Open Services > SMB/CIFS > Settings, tick Enabled at the top and leave the workgroup as WORKGROUP unless your Windows machines use another one.

Scroll to Advanced settings before you save. Minimum protocol version defaults to SMB2, which blocks SMB1 clients, and NetBIOS is off, so the server does not show up in old-style network browsing. Leave both alone unless an old printer or media player forces SMB1, because SMB1 is the dialect the Linux kernel itself warns about when you request it.

Save and apply, then switch to the Shares tab and click +. Select the media shared folder, add a comment if you like, and keep Public set to No so every connection needs a login. Leave Read-only unticked: the per-user privileges from Step 4 already make viewer read-only, and ticking it here would lock out nasuser as well.

After Apply, check what openmediavault generated. SSH to the NAS (as a member of _ssh) and print the effective Samba configuration:

sudo testparm -s

The [media] section is where the privileges from Step 4 land. valid users lists everyone with any access, write list holds nasuser and read list holds viewer:

[media]
	comment = Media share on nas01
	create mask = 0664
	directory mask = 0775
	force create mode = 0664
	force directory mode = 0775
	hide special files = Yes
	path = /srv/dev-disk-by-uuid-8de14a77-a2de-48ea-9930-bdc1713ea538/media/
	read list = viewer
	read only = No
	store dos attributes = No
	valid users = nasuser viewer
	write list = nasuser

If a user you expected is missing from valid users, the privilege was saved but not applied, or the account has No access on the Permissions page. Fix it there and apply again rather than editing smb.conf, because openmediavault regenerates that file on every apply and your edit would vanish.

Step 6: Enable NFS and export the same folder

NFS has its own service switch. Open Services > NFS > Settings, tick Enabled and keep the default versions (NFSv3, NFSv4, NFSv4.1 and NFSv4.2) so both older and current clients can mount.

Save and apply, then go to the Shares tab and click +. Select media, set Client to the subnet allowed to mount it, and change Permission from the default Read-only to Read/Write. The form takes one client entry per share, so the lab used the subnet 10.0.1.0/24 rather than a single IP. If two networks need different access, add a second NFS share for the same shared folder with the other client and its own options. We tried that with a read-only entry for a second subnet, and openmediavault merged both onto one /export/media line in /etc/exports, each client with its own options. Leave Extra options at subtree_check,insecure for now.

Once it is applied, list the active exports on the NAS with the options the kernel actually uses:

sudo exportfs -v

openmediavault exports a read-only pseudo root at /export (fsid=0) and the folder under it. Read the defaults the form did not show you, root_squash and no_all_squash, because they decide the first NFS error in Step 8:

/export/media 	10.0.1.0/24(sync,wdelay,hide,fsid=2b4cd048-5520-4149-9f98-1a4f48fa39d4,sec=sys,rw,insecure,root_squash,no_all_squash)
/export       	10.0.1.0/24(sync,wdelay,hide,fsid=0,sec=sys,ro,insecure,root_squash,no_all_squash)

The pseudo root changes the mount path by protocol version. An NFSv4 client mounts 10.0.1.50:/media, relative to fsid=0, while an NFSv3 client needs the full 10.0.1.50:/export/media. We tested both pairings and the swapped ones. NFSv4 against /export/media failed with “reason given by server: No such file or directory”. NFSv3 against /media failed with “access denied by server”. Either message on a fresh mount usually means the path and the version do not match.

Step 7: Mount the SMB share on a Linux client

The kernel CIFS client needs cifs-utils for the mount helper, and smbclient is the quickest way to prove the login works before you mount anything. On Ubuntu and Debian install both, plus nfs-common for the next step:

sudo apt install -y cifs-utils smbclient nfs-common

On Rocky Linux, AlmaLinux and Fedora the packages are cifs-utils, samba-client and nfs-utils, installed with sudo dnf install. We ran the client side on Ubuntu only. Keep the password out of shell history and out of /etc/fstab by putting it in a root-only credentials file. Create one file per NAS account.

sudo vim /root/.smb-nasuser

Add the account name and its password, one per line:

username=nasuser
password=ChangeMe-Example1

Restrict it to root, since anyone who can read it can log in as that user:

sudo chmod 600 /root/.smb-nasuser

List the shares the NAS offers to that account. This checks the password, the SMB service and the network path in one command:

sudo smbclient -L "//${HOST_IP}" -A /root/.smb-nasuser

A healthy result lists media with the comment from Step 5. The “SMB1 disabled” line is expected with the SMB2 minimum from Step 5, because the old workgroup browse list needs SMB1:

	Sharename       Type      Comment
	---------       ----      -------
	media           Disk      Media share on nas01
	IPC$            IPC       IPC Service (nas01 server)
SMB1 disabled -- no workgroup available

Create a mount point and mount the share. The uid and gid options make every file appear owned by your local user, which is the simplest mapping for a single-user client. The shell fills in your own IDs from id -u and id -g (1000 on our client). mount.cifs(8) documents two alternatives, neither tested here. One is the multiuser option with cifs.idmap and per-user credentials. The other is the SMB3 POSIX extensions, which also need support enabled on the Samba side:

sudo mkdir -p /mnt/media-smb
sudo mount -t cifs "//${HOST_IP}/media" /mnt/media-smb -o credentials=/root/.smb-nasuser,uid=$(id -u),gid=$(id -g)

Confirm the mount and the dialect it negotiated. A mount that silently fell back to an older dialect still works, but it loses the encryption and multichannel support of SMB 3.x, so this is worth a glance once.

findmnt /mnt/media-smb -o TARGET,SOURCE,FSTYPE,OPTIONS

Look for vers=3.1.1, the newest SMB dialect, and username=nasuser. We set no size options, so the 4 MiB rsize and wsize are what this client negotiated by default, and they were in effect for the benchmark in the table:

TARGET         SOURCE            FSTYPE OPTIONS
/mnt/media-smb //10.0.1.50/media cifs   rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=nasuser,uid=1000,forceuid,gid=1000,forcegid,addr=10.0.1.50,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,reparse=nfs,nativesocket,symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1

A test write as nasuser succeeded and the file showed up on the NAS owned by nasuser:users. We then remounted with a /root/.smb-viewer credentials file: reading the same file worked, and a write was refused, which is the read-only privilege doing its job:

touch: cannot touch '/mnt/media-smb/viewer-write.txt': Permission denied

From Windows the same share is \\10.0.1.50\media in File Explorer or Map Network Drive, with the NAS account as the login. We did not test a Windows client in this run, so we have no Windows numbers or screens to show.

Step 8: Mount the NFS share and map the client UID

NFS has no login, so the NAS trusts the numeric UID and GID the client sends with every request. Check what the NAS exports to this client first:

showmount -e "${HOST_IP}"

Both the pseudo root and the folder should be listed for your subnet. If /export/media is missing, the share was saved but not applied, so go back to the yellow banner on the NAS before you debug the client:

Export list for 10.0.1.50:
/export       10.0.1.0/24
/export/media 10.0.1.0/24

Mount it with NFSv4, using the path relative to the pseudo root. We prefer v4 for a single client like this one because it runs over one TCP connection to port 2049 and needs no helper daemons. Our NFSv3 test mount had to start rpc-statd on the client for locking, and the v4 mount did not.

sudo mkdir -p /mnt/media-nfs
sudo mount -t nfs4 "${HOST_IP}:/media" /mnt/media-nfs

The mount came up as vers=4.2 over TCP with 256 KiB read and write sizes. Then the first write failed, both as the normal user and with sudo:

touch: cannot touch '/mnt/media-nfs/nfs-test.txt': Permission denied
touch: cannot touch '/mnt/media-nfs/nfs-root-test.txt': Permission denied

Both failures are correct behaviour. The client user is UID 1000, which on the NAS is the Debian install account. That account is not in users, so the 2775 directory only gives it read access. Root on the client is mapped to nobody by root_squash, and nobody cannot write there either. One fix is matching UIDs on every client, which is the right answer for a fleet run from LDAP. The other is to map every client user to one NAS account in the export, which is what most home and small-office setups want.

We took the second route. Edit the NFS share and append all_squash,anonuid=1001,anongid=100 to Extra options, where 1001 is the UID of nasuser from Step 3 and 100 is the users group.

After Apply, exportfs -v on the NAS showed anonuid=1001,anongid=100 and all_squash on /export/media. We unmounted and mounted the share again before the retest, so the client started from a clean mount:

sudo umount /mnt/media-nfs
sudo mount -t nfs4 "${HOST_IP}:/media" /mnt/media-nfs

Both writes then succeeded. On the NAS, every file, including the one root created, belongs to nasuser:

-rw-r--r-- 1 nasuser users  0 Oct 16 16:22 nfs-root-test.txt
-rw-rw-r-- 1 nasuser users  0 Oct 16 16:22 nfs-test.txt
-rw-rw-r-- 1 nasuser users 20 Oct 16 16:20 smb-test.txt

That is the useful property of this setup: files written over NFS and over SMB end up with the same owner, so either protocol can edit the other’s files. The cost is that every NFS client becomes nasuser, including root on any host in the subnet, so keep the Client field as narrow as your network allows. The exports(5) man page documents every squash option if you need a different mapping.

Step 9: Make both mounts permanent in fstab

A plain fstab line for a network share is a boot risk: if the NAS is down, the client can sit at boot waiting for it. The options below avoid that. _netdev waits for the network, nofail lets boot continue without the share, and x-systemd.automount mounts it on first access instead of during boot. Unmount the test mounts, then open fstab:

sudo umount /mnt/media-smb /mnt/media-nfs
sudo vim /etc/fstab

Append these two lines. fstab does not expand shell variables, so type the NAS address literally and replace 1000 with the output of id -u and id -g if yours differ:

//10.0.1.50/media /mnt/media-smb cifs credentials=/root/.smb-nasuser,uid=1000,gid=1000,_netdev,nofail,x-systemd.automount 0 0
10.0.1.50:/media /mnt/media-nfs nfs4 _netdev,nofail,x-systemd.automount 0 0

Reload systemd so it generates the automount units, and mount everything to catch typos now rather than at the next boot:

sudo systemctl daemon-reload
sudo mount -a

We rebooted the client to prove the entries. Straight after boot, both paths are autofs placeholders owned by systemd, and the first ls into each one mounts the real share. This is findmnt after the first ls:

TARGET         SOURCE            FSTYPE
/mnt/media-nfs 10.0.1.50:/media  nfs4
/mnt/media-smb //10.0.1.50/media cifs

If you would rather mount NFS shares only on demand from a central map, the autofs setup does the same job without fstab. That suits laptops and hosts that see several NAS boxes, because a central map is easier to change than an fstab line on every machine.

For clients that reread the same large files, a local FS-Cache for the NFS mount takes repeat reads off the network. It helps most on Wi-Fi clients, where the 118 MB/s in the table is out of reach anyway and a local SSD cache is several times faster.

Fix OpenMediaVault share permission errors

These are the errors we hit on the test pair, in the order a new setup usually meets them. Each one names the layer that refused the request, which tells you which page in the workbench to open.

mount error(13): Permission denied

Error 13 on a CIFS mount has two causes that look the same on the command line, and dmesg tells them apart. The first is a failed login: Samba has no password entry for the account, or the password is wrong. dmesg names it STATUS_LOGON_FAILURE:

CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE
CIFS: VFS: \\10.0.1.50 failed to create a new SMB session with Unknown: -13

We got that by logging in as klinsmann, the account created by the Debian installer. It is a valid Linux user, but pdbedit -L on the NAS listed only nasuser and viewer, so Samba had no password for it. A wrong password for nasuser gave the same session failure. Set or reset the password under Users > Users so openmediavault writes the Samba password too.

The second cause is a valid login to a share the account may not open. We set viewer to No access on the Permissions page, which openmediavault writes as invalid users = viewer, and mounted with its credentials. The login succeeded, so dmesg showed no status line at all, only the failure:

CIFS: Attempting to mount //10.0.1.50/media
CIFS: VFS: cifs_mount failed w/return code = -13

smbclient names the difference directly. The No access account gets past session setup and is refused at tree connect, while the wrong password never gets a session:

tree connect failed: NT_STATUS_ACCESS_DENIED
session setup failed: NT_STATUS_LOGON_FAILURE

For the tree connect case the fix is on the shared folder’s Permissions page: give the account Read-only or Read/Write and apply. We set viewer back to Read-only afterwards and its mount worked again.

mount error(95): Operation not supported

The client asked for a dialect the server refuses. We forced vers=1.0 against the default SMB2 minimum, and the kernel logged the SMB1 warning before failing with return code -95:

CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers
CIFS: Attempting to mount //10.0.1.50/media
CIFS: VFS: cifs_mount failed w/return code = -95

Remove the vers= option and let the client negotiate, which gave 3.1.1 here. Lower the server minimum to SMB1 only for a device that cannot speak anything newer, and accept that the whole NAS then accepts the old protocol.

Permission denied on a folder created over SSH

An admin who creates a directory inside the share as root, with sudo mkdir over SSH, gets root’s umask. Our archive folder came out as drwxr-sr-x root users, with no group write. nasuser still had its Read/Write privilege, but the kernel refused the write, which is the Step 4 rule in action:

touch: cannot touch '/mnt/media-smb/archive/report.txt': Permission denied

The fix is on the file system layer. Select the shared folder, click Access control list, tick Recursive, and keep group users at Read/Write/Execute. Check two fields before you click Save, because the defaults rewrite more than the broken folder. Replace is ticked by default and Owner defaults to root, so with Recursive the save chowns every file in the share to root and adds execute bits to all of them. On a share that already holds data, set Owner to the account that should own the files, or set the relative path to the one broken subfolder instead of /.

We saved it with the defaults on the test share to see the effect. archive became drwxrwsr-x and the same touch succeeded, but every existing file changed owner from nasuser to root and became -rwxrwxr-x. Writes kept working through the users group, which is why the damage is easy to miss until someone audits ownership.

The same two layers apply on other NAS platforms: TrueNAS calls them share ACLs and dataset permissions, as our TrueNAS SMB, NFS and WebDAV shares guide shows. The error messages on the client are identical, so the order of checks above carries over: login first, protocol second, file system mode last.

If you are still deciding what runs the shares, the DIY NAS vs prebuilt comparison weighs openmediavault on your own hardware against a boxed unit.