What is it?

This is a plugin to let you create SMB shares for any folder on your server - including sub-folders within existing shares.

Install via Community Applications or manually:

https://raw.githubusercontent.com/cslemieux/unraid-custom-smb-shares/main/custom.smb.shares.plg

Why?

I followed the TRaSH Guides folder structure to set up hardlinks for my *arr apps. The structure looks like:

/mnt/user/data/
          ├── torrents/
          ├── usenet/
          └── media/
              ├── movies/
              ├── tv/
              └── music/

Problem is, Unraid only lets you share top-level folders. I wanted to share /mnt/user/data/media/movies/ directly without exposing everything else. This plugin does that.

Features

- Create shares for any folder under /mnt/

- Enable/disable without deleting

- Clone shares

- Import/export as JSON

- Security modes (Public/Secure/Private)

- User/group access control

- macOS + Time Machine support

- Path browser for easy folder selection

- Host allow/deny lists

Notes

- Shares are managed separately from Unraid's built-in shares

- Uses your existing system users for access control

- Automatically reloads Samba after changes

Source

GitHub: https://github.com/cslemieux/unraid-custom-smb-shares

Let me know if you run into any issues!

Edited April 1Apr 1 by zapbranagann
Screenshots

Changelog (newest to oldest):

v2026.06.18 is now live:
- GitHub Release: https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.06.18 (https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.06.18)
Quick follow-up to the menu-placement feature from v2026.06.17.
- Fixed: Changing "Show in top menu bar" and clicking Apply now updates the top navigation right away. Previously the SMB Shares tab would stick around until you did a manual browser hard refresh (Ctrl+Shift+R). To be clear, the setting itself always saved correctly — this was only the Unraid menu not redrawing. Toggling it now forces the menu to rebuild on the spot.
- Improved: 6 new regression tests pin the menu-refresh behavior so it can't sneak back.

v2026.06.17 is now live:
- GitHub Release: https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.06.17 (https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.06.17)
Two community-requested features — thanks dc911x and johnoldiges!
- Added: Configurable menu placement (thanks dc911x). A new "Show in top menu bar" setting lets you keep SMB Shares as a tab in the top navigation bar (the default — nothing changes for existing installs) or move it down to Settings then User Utilities, like most plugins.
- Added: Option to allow share paths outside /mnt (thanks johnoldiges). A new opt-in setting (off by default) lets you point a share at a path like /tmp. System directories (/boot, /etc, /var, and friends) stay blocked even when it's enabled, and the check follows symlinks so they can't be used to sneak around the block.
- Improved: 22 new automated tests covering both features (all passing).

v2026.05.18b is now live:

- GitHub Release: https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.05.18b (https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.05.18b) Bug fix release based on follow-up testing from comet424 — thanks again!

- Fixed: Picking a folder via the Browse button on the Edit page now properly enables the Apply button. Previously the path field updated visually but Apply stayed disabled until you also typed something into the share name or comment field. Root cause: Unraid's form-state tracking watches change/input events to know when to enable Apply, and the Browse picker was setting the path silently via $.val() (which doesn't fire those events). Now mirrors the Docker plugin pattern by firing a change event after the picker updates the path. Typing a path manually still works as before.

- Improved: 2 new E2E regression tests pin the change-event behavior on both Add and Edit pages so this doesn't regress (now 442 tests, all passing).


v2026.05.18a is now live:
- GitHub Release: https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.05.18a (https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.05.18a)
Changes in this release (patch on top of v2026.05.18):
- Fixed: Import from File now actually imports the selected file. Previously it was a silent no-op — the modal would disappear with no notification because of a SweetAlert quirk during file picker interaction.

v2026.05.18 is now live:
- GitHub Release: https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.05.18 (https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.05.18)
Bug fix release based on detailed reports from comet424 — thank you!
- Fixed: Import Config (file + paste) now works. Was silently 400-ing because the server was reading the request body wrong. You'll also now get a proper error message if anything goes wrong.
- Fixed: Restore from backup actually restores AND reloads Samba. Previously it updated shares.json but Samba kept serving the old config — appeared to "do nothing." Now also surfaces a real error message if a restore fails (instead of generic "Failed to restore"), and won't trash your backup retention on failed retries.
- Fixed: First-row Delete/Clone failing on shares whose names had stray whitespace or invisible characters. Added auto-cleanup so the bug can't come back even if you restore from an older "dirty" backup.
- Fixed: Picking a path via Browse on the Edit page no longer silently renames your share to the folder name (regression from the v2026.04.06 rename feature).
- Improved: 24 new automated tests + 2 new E2E tests covering these specific bugs (440 tests total, all passing).

v2026.04.06 is now live:
- GitHub Release: https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.04.06 (https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.04.06)
Changes in this release:
- You can now rename shares from the Edit page — the share name field is editable (thanks benfishbus for reporting!)
- Added duplicate name check when renaming — prevents accidentally overwriting another share's name
- Fixed submit button not resetting after validation errors

v2026.04.01d:
- GitHub Release: https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.04.01d (https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.04.01d)
Changes in this release:
- Share name validation now allows all valid SMB characters (spaces, dots, accents, etc.) — only truly forbidden characters are blocked: [ ] " / \ : ; | < > , ? * = (thanks Squid for the PR!)
- Path input is now editable — you can type or paste paths directly instead of click-only browsing
- Browse button still available for directory selection
- FileTree dropdown no longer stretches across the full form width
- Removed unused legacy script (generate-config.sh)
- Added E2E tests to CI pipeline
- Plugin is now available in Community Applications! 🎉

v2026.02.10:
- GitHub Release: https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.02.10 (https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.02.10)
- Added a File Browser link — browse icon next to each share's path opens Unraid's built-in File Browser

v2026.01.20:
- GitHub Release: https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.01.20 (https://github.com/cslemieux/unraid-custom-smb-shares/releases/tag/v2026.01.20)
- Force user/group fields changed from text inputs to dropdowns
- Only valid system users/groups are selectable (prevents config errors)
- Default is now "None" (use connecting user) instead of hardcoded nobody/users
- Auto-expand Advanced View when editing shares with advanced settings configured

v2026.01.19:
- Fixed user access permissions not enabling the "Apply" button

Edited June 18Jun 18 by zapbranagann

This is what I needed! Great work!

Bug:

When editing permissions (SMB User Access), modifying any access for the users will not enable the "Apply" Button.

Edited January 4Jan 4 by adelzu

On 1/4/2026 at 5:55 AM, adelzu said:

This is what I needed! Great work!

Bug:

When editing permissions (SMB User Access), modifying any access for the users will not enable the "Apply" Button.

Thanks I'll take a look and fix.

Updated the plugin v2026.01.19 should fix the issue with user access permissions not enabling the "Apply" button.

On 12/14/2025 at 8:23 PM, zapbranagann said:

Install via Community Applications (pending)

Any idea when this might occur? (Many of us are reluctant to install plugins that are not in the App Store...)

I wanted to get some early feedback first before publishing to community applications. I can check with Squid to see if there are any other requirements to publish.

7 hours ago, zapbranagann said:

I wanted to get some early feedback first before publishing to community applications. I can check with Squid to see if there are any other requirements to publish.

Just make sure that 'Life' will allow you some extra time to deal with any issues or bugs that a wider release might reveal...

On 12/14/2025 at 8:23 PM, zapbranagann said:

Install via Community Applications (pending) or manually:

https://raw.githubusercontent.com/cslemieux/unraid-custom-smb-shares/main/custom.smb.shares.plg

By the way, this link (in both Firefox and Chrome) takes to a listing of the code and does not trigger the download for the actual .plg file. If you want wider participation, change the link to provide the actual install file needed.

2 hours ago, Frank1940 said:

By the way, this link (in both Firefox and Chrome) takes to a listing of the code and does not trigger the download for the actual .plg file. If you want wider participation, change the link to provide the actual install file needed.

That is the plg file and is what you need to enter in unraid's "install plugin" field.

44 minutes ago, Kilrah said:

That is the plg file and is what you need to enter in unraid's "install plugin" field

Mental Neutral on my part. As soon as I realized I had to enter the URL, everything make sense!

OK--- I just made a couple of quick tests and I observed this:

The standard Unraid permissions for directories are 777 and for files are 666. I did not do a lot of testing but it is possible that there may be some issues when people are accessing using 'Public' permissions. Unraid security setup and permissions are a bit funky and I would strongly suggest that you conform to their standard. (I can not remember for sure if 'nobody' is a member of the 'users' group.

Next item— Look at these two directories:

The directory names should indicate how they were created. Notice the one created by your plugin has 'nobody' as the owner whereas the one created using a standard Unraid Share has my SMB login name– user –as the owner. Notice that it also has the stand Unraid permissions. The owner of 'nobody' is not a real issue in this case but it can mask some access issues with the 'other' permissions. (I rue the day when I decided on using 'user' as my SMB login. It is not a problem in day-to-day usage but complicates things when I composing a reply on the forum! 🫤)

2 minutes ago, Frank1940 said:

can not remember for sure if 'nobody' is a member of the 'users' group.

From New Permissions page:

The utility starts a background process that goes to each of your data disks and cache disks and selected user shares and changes file and directory ownership to nobody/users (i.e., uid/gid to 99/100), and sets permissions as follows:

For directories:
  drwxrwxrwx

For read/write files:
  -rw-rw-rw-

For readonly files:
  -r--r--r--

nobody is actually better than a specific user. The share SMB access is applied before linux access is considered, but a specific user for owner could deny access unless permissions give access to the group (which they should anyway).

7 minutes ago, trurl said:

nobody is actually better than a specific user. The share SMB access is applied before linux access is considered, but a specific user for owner could deny access unless permissions give access to the group (which they should anyway).

A few years ago, this was how Unraid behaved. It used nobody as the owner of everything on the array. Then something changed (at least in Samba) and, if you were logged in as a Share Access user with valid Share Access credentials, any file you created, you ended up as owner. From my previous research into how Unraid SMB works, I found out that all Share Access users are automatically members of the users Group. Thus they always have access via the Group using group permissions regardless of who the owner is. What I can''t remember at this point (I getting older and my memory is not as good as It once was) is if nobody is also a member of the users group. (IF I remember correctly, a Share Access login with a bad user name is automatically logged is using the guest account and I think is assigned as nobody.)

As a matter of information, you might want to google nobody Linux and read how this user name came about. it was an semi-hack to fix/solve a problem many years ago. The New Permissions Tool has to change the owner to some user (assuming that the owner name is a problem to be addressed) and nobody is a convenient, harmless one that is ready to use.

Edited January 20Jan 20 by Frank1940

Interest find! If, on the Edit page/tab, you switch from Basic View to Advance View, you get these additional settings. I did test and, with these settings I can get directories with 777 permissions and files with 666 permissions. (I checked to add the write permission of 'Others' for both File and Directory.)

Looks like a simple solution. But I still think that the out-of-box permissions should be 777 and 666. Then if the user requires something different, they can make the changes required using these Advanced View Settings.

Demo of results:

@zapbranagann, Looking really good from my perspective!!!

3 hours ago, Frank1940 said:

A few years ago, this was how Unraid behaved.

Still does.

3 hours ago, Frank1940 said:

is if nobody is also a member of the users group.

It is.

1 hour ago, Frank1940 said:

on the Edit page/tab

Is this a page in stock Unraid, or only appears when you have this plugin installed?

1 hour ago, trurl said:

Is this a page in stock Unraid, or only appears when you have this plugin installed?

It is an option in the actual plugin:

I found a problem. Forcing a user does not change a newly written file's owner to be what the 'Force user:' setting is. It still remains at 'nobody. (I tried two different valid Share Access users to verify this problem. I even restarted Samba...)

Edited January 20Jan 20 by Frank1940

5 minutes ago, Frank1940 said:

I found a problem. Forcing a user does not change a newly written file's owner to be what the 'Force user:' setting is. It still remains at 'nobody. (I tried two different valid Share Access users to verify this problem. I even restarted Samba...)

Thanks for the thorough testing, I'll take a look to see why it's not picking up that config change.

[EDIT] I just thought to clarify, I believe force user will only apply to file/folders created after the config is set, I assume that's what you meant by "newly written" but I figured it wouldn't hurt to confirm. [/EDIT]

So when I test locally, it seems to work for me. The force user and force group get written directly into the Samba configuration, can you check using the terminal/shell the configuration that's being generated?

The file /boot/config/plugins/custom.smb.shares/smb-custom.conf is the plugin's generated Samba config (included by main smb.conf). To check the actual Samba config being used:

cat /boot/config/plugins/custom.smb.shares/smb-custom.conf

And to verify whether it's being included properly:

grep -i "include.*custom" /etc/samba/smb.conf

You should see a list of shares each with the following format in (smb-custom.conf):

[books]
    path = /mnt/user/data/media/books
    comment = Books
    browseable = yes
    vfs objects = catia fruit streams_xattr
    guest ok = yes
    read only = no
    force user = zapbranagann
    force group = users
    create mask = 0664
    directory mask = 0775
    hide dot files = yes

Do your shares have the correct force user fields set? If so, that's the limit of what the plugin can do right now, and there might be something else interfering with the samba force user config.

Edited January 20Jan 20 by zapbranagann

Not sure what is going on.... Here is the output from testparm

In case you are not familiar with this tool, the [global] section is a list of parameters which have been changed from their Samba defaults. (If you run this program with the -v switch, you will get the output from every Samba parameter and its setting. Interesting to do if you want to see how configurable Samba is!)

Here is the output of the smb-custom.conf. (I have my Flash drive shared out– read-only –so I can look at the files on it from my Windows computer.)

I got it to work. I ended up stopping and starting the array. This, of course, forces a complete reboot of Samba. I could swear I had used your RELOAD SAMBA button BUT perhaps I didn't. I only remember that it seemed to happen in a fraction of a second.

13 minutes ago, Frank1940 said:

I got it to work. I ended up stopping and starting the array. This, of course, forces a complete reboot of Samba. I could swear I had used your RELOAD SAMBA button BUT perhaps I didn't. I only remember that it seemed to happen in a fraction of a second.

I'm glad to hear it worked, the only idea I had left was perhaps there was a issue involving whitespace/case/typo, I don't think testparm validates that the force user/group exist.

I've pushed a new release which changed to drop-down fields for force user and force group to help remove potential errors/typos/etc. It now populates the valid users and groups from unraid (including system accounts) so it should work the same as the text input field without restricting what can be entered.

2 hours ago, zapbranagann said:

I've pushed a new release which changed to drop-down fields for force user and force group to help remove potential errors/typos/etc. It now populates the valid users and groups from unraid (including system accounts) so it should work the same as the text input field without restricting what can be entered.

I downloaded the new release. I reset the 'user' drop-down field to 'None– use connecting user' and it worked just fine.

I did notice that the drop-down option lists are long and include every user and group on the entire system. This may prove to be overwhelming to many folks but lets wait and see what happens. I am assuming that you have made the defaults using the "None– using..." entry. That will probably work just fine for 99.999% of all users!

One more observation. There is no link to the built in Unraid File Browser. Let me give you examples.

For User and Disk Shares (Oval shows link to File Browser) :

For Mounted Shares:

For Array Devices:

I have no idea how difficult it might be to add in the link to the Unraid File Explorer but it would be a very nice addition if it could be done.