How to Create a Shared Folder in OpenMediaVault 8

Here is how to create a shared folder in OpenMediaVault 8: mount your data filesystem under Storage > File Systems, open Storage > Shared Folders, click Create, enter a name, pick that filesystem, keep the suggested relative path and the default permission mode, then Save and Apply. The folder is not on the network until you publish it under Services > SMB/CIFS > Shares.

That last step is where most first setups stall. In OMV a shared folder is a database record: a filesystem UUID, a relative path, a permission mode and a list of user privileges. SMB, NFS and the Docker compose plugin all point at that record, so getting it right once saves redoing permissions on every share later. Budget fifteen minutes, plus however long Windows spends clinging to a cached guest login.

What has to exist before you start?

You need three things: OMV installed on its own system disk, a data filesystem mounted through the web interface, and at least one normal user account. OMV 8 “Synchrony” on Debian 13 is the current stable release per the official release table, and the menu paths below come from it.

The system disk is off limits: the prerequisites page says it “cannot officially be used for shared resources or as user data drive”. If you are still choosing a data disk, the OpenMediaVault hardware requirements guide covers what is worth buying, and OpenMediaVault filesystems and shared folders explained covers the layout decisions that come first.

Create users under Users > Users. The users documentation notes that every user created in the web interface lands in the users group (gid 100), which the default shared folder permissions are built around. Keep the web admin account for administration and log into shares as a normal user.

Step 1: confirm OMV knows about the filesystem

Open Storage > File Systems and check that your data filesystem is listed and mounted. OMV mounts data under /srv/dev-disk-by-... paths, and the filesystems documentation is blunt about the trap: drives “not mounted through the web interface are not registered in the backend database”, so they cannot hold shared folders. An fstab line left over from an earlier Debian install does not count.

If the disk already holds data, use the option to mount an existing filesystem. Clicking Create on a disk full of files formats it.

Step 2: create the shared folder

Go to Storage > Shared Folders and click Create. The shared folders documentation describes the fields:

• Name. The logical name, which also becomes the default SMB share name. Typing it fills the path with the same string. Use lowercase and no spaces; your compose files and NFS mount lines will thank you.
• File system (the docs call it the device). The mounted filesystem the folder lives on.
• Relative path. The directory inside that filesystem. Typing / shares the whole disk, which puts container configs, backups and every stray directory under one set of permissions. Don’t.
• Permissions. The POSIX mode for the new directory.
• Comment. Optional, and handy once you have six folders called some variant of “stuff”.

Click Save, then Apply in the pending-changes banner. Nothing is written until you do. The permission dropdown maps to six modes:

The default 775 suits most home setups: everyone in users can write, and guests or container users outside the group can read. Pick 770 for anything personal. Resist 777; it silences permission errors the way pulling the battery silences a smoke alarm.

Step 3: give users and groups privileges

Select the folder and click Permissions. For each user and group, choose Read/Write, Read-only or No access. The usual pattern is the users group on read/write for common folders like media, and individual users on their private folders with everyone else set to No access.

Privileges are not filesystem permissions. The SMB documentation says they “will not act in the file system layer, they will run in the Samba authentication layer”, where OMV writes them as valid users, read list and write list. The users documentation adds that access must be sufficient “on both the service level and the filesystem level”. NFS ignores privileges entirely.

The ACL button covers what mode bits cannot. It works only on native Linux filesystems: the documentation notes it is disabled for NTFS, FAT and HFS+, and ZFS needs ACL support enabled on the dataset. Its best trick is a repair: tick the recursive box and change only the bottom POSIX panel, selecting no ACL user or group, to reset Linux permissions across the folder. That cleans up files copied in as root over SSH.

Step 4: publish the folder over SMB

Under Services > SMB/CIFS > Settings, tick Enabled, Save and Apply. Then open Shares, click Create and pick your shared folder. Three options decide how the share behaves:

• Public. Set to no, login is always required. With guests allowed, anyone who skips login becomes the guest; with guests only, everyone does. The guest maps to the system user nobody, which is not in users, so under the default mode guests can read but not write.
• Read only. The docs warn it “overrides privileges and POSIX”. If writes fail and everything else looks right, check this box first.
• Inherit permissions. Forces a 664 creation mode so files one user creates stay writable by the rest of the group. Enable it on any share more than one person writes to.

Save, Apply, connect. On Windows, use Map network drive with \\192.168.1.50\media and tick “Connect using different credentials”, the route the SMB docs suggest for logging in as someone other than guest. Windows keeps one set of credentials per server, so if it connected as guest earlier, net use * /delete drops the cached session. On macOS, Finder’s Go > Connect to Server takes smb://192.168.1.50/media. On Linux, with cifs-utils installed:

sudo mount -t cifs //192.168.1.50/media /mnt/media -o username=alice,uid=$(id -u),gid=$(id -g)

If copies crawl once it works, the SMB speed checklist tests network, disks, Samba and client in the order that finds the bottleneck.

Sharing the same folder over NFS

Enable NFS under Services > NFS > Settings, then add a share with three fields: the shared folder, the client (an IP, hostname or network such as 192.168.1.0/24), and read/write or read-only. Per the NFS documentation, OMV bind-mounts the folder under /export, the NFSv4 pseudo root.

The same page carries the warning that matters: NFS “relies on uid/gid matching” and “doesn’t provide any authentication/security at all”. Use it for Linux boxes and hypervisors on a LAN you trust; use SMB for laptops.

sudo mount 192.168.1.50:/media /mnt/media          # NFSv4
sudo mount 192.168.1.50:/export/media /mnt/media   # NFSv3

Why can’t I write to my new share?

Because one of three layers says no: the SMB share is read only or you connected as guest, the shared folder privileges give your user read-only or no access, or the directory’s mode or ACL blocks your user. Check them in that order. From an SSH session on the NAS:

ls -ld /srv/dev-disk-by-uuid-*/media
getfacl /srv/dev-disk-by-uuid-*/media
grep -A 25 '^\[media\]' /etc/samba/smb.conf
id alice

The ls line should show group users with write permission on a 775 or 770 folder. getfacl reveals any ACL entries layered on top. The Samba section shows the read only, guest ok and user lists OMV generated. id confirms the user is actually in users; accounts created outside the web interface often are not.

Changing or deleting a shared folder later

Shared folders are easy to create and fussy to remove, by design. The shared folders documentation lists the constraints:

• You cannot delete a shared folder while a service uses it. Remove the SMB share, NFS share or compose setting first.
• Changing the filesystem of an existing shared folder “will not move the data from one filesystem to another”. Move the files yourself.
• You cannot unmount a filesystem while shared folder entries still reference it.
• For NFS shares, edit the share in the NFS section; changing the parent device does not update the bind mount in /etc/fstab.

A layout that still makes sense at month nine

Make one shared folder per access pattern, not per hobby. For most single-box homelabs that means media (775, group read/write, SMB with inherit permissions), documents (770, per-user privileges), backups (770, backup user only), and appdata with no SMB share at all. The OMV 8 Docker Compose setup guide walks through the appdata and data folders the compose plugin expects, and keeping container configs off the network stops anyone from “tidying up” a live database.

Shared folders are also the natural unit for backups. Disk redundancy is not a backup; a scheduled copy of media and documents to a second machine or USB disk is the part everyone skips until month nine.

FAQ

Where are shared folders stored in openmediavault?

Shared folders are ordinary directories on your data disk, under the filesystem’s mount point at a path like /srv/dev-disk-by-uuid-1234/media. OMV stores the definition, meaning filesystem UUID, relative path and privileges, in its config.xml database. That is why renaming the directory by hand breaks things: the database still points at the old relative path.

Can I create a shared folder on the openmediavault system disk?

Not officially, because the documentation rules out the system drive for shared resources and user data, so the shared folder form will not offer it. The omv-extras sharerootfs plugin works around the restriction, and it is fine for a one-disk Raspberry Pi experiment. For anything you care about, a cheap second SSD or HDD is the supported route.

Can openmediavault share an NTFS drive?

Yes, OMV can mount an existing NTFS drive and create shared folders on it, but it cannot format one, and the ACL editor is disabled for NTFS. Expect coarser permission control than on ext4 or XFS. Treat NTFS as a migration step: copy the data onto a native Linux filesystem, then reformat the drive.

Do I need an SMB share for every shared folder in openmediavault?

No. A shared folder only needs an SMB or NFS share if other computers open it over the network. Folders used only by containers, rsync jobs or local services work fine without one, and leaving them unshared keeps container databases and config files away from people browsing the network from a laptop.