Simple NAS – Turn your Home Assistant into a full NAS with Web GUI
Hi everyone!
I built a Home Assistant add-on that turns your Raspberry Pi (or any HA hardware) into a simple NAS with Samba file sharing and a built-in web interface — no SSH or config files needed.
Why?
I wanted a straightforward way to share USB drives connected to my Raspberry Pi 5 running HA OS, without the complexity of existing Samba add-ons. I needed something where I could plug in a drive, create a share, manage users — all from within Home Assistant.
Features
Samba file server (SMB/CIFS) — access your shares from Windows, macOS, Linux, and other apps like Nextcloud
Web GUI integrated in HA — manage everything via Ingress, no separate web interface needed
Drive management — detect, mount, and unmount USB drives directly from the GUI (supports ext4, NTFS, exFAT, btrfs, XFS, FAT32)
Share management — create, edit, and delete Samba shares with a few clicks
Users & Groups — create Samba users with passwords, organize them in groups, assign per-share access
Network discovery — your NAS automatically appears in Windows Explorer (WS-Discovery), Linux file managers (Avahi/mDNS), and macOS Finder
Dark/Light theme — matches the HA look and feel, switchable in the header
System protection — warning dialog when trying to mount/unmount system partitions (sda)
Persistent configuration — all shares, users, groups, and mounts survive add-on restarts and updates
Configurable web port — change the GUI port if 8099 conflicts with something else
Hi I just switched over to Simple NAS from the standard Samba NAS add-on, and the difference is night and day.
Your version is so much easier to handle, especially for managing external drives. Most importantly for me: it runs significantly better with macOS. Finder picks up the shares instantly and the connection is much more stable than what I experienced before.
Läuft super! Really appreciate you putting this together and making NAS functionality accessible for everyone.
One quick question: Is there (or could there be) an option to exclude specific files? I’d love to prevent macOS from cluttering the shares with its ‘junk’ files (like .DS_Store, ._* files, or .TemporaryItems).
However, I’ve run into another issue: When rebooting the host or restarting the add-on, the device assignments (like /dev/sda vs /dev/sdb) sometimes swap. This leads to the wrong drives being mounted to the wrong share paths.
this looks awesome, thanks for sharing! i’ve been wanting something like this for ages—just plug in a usb drive and go, no messing with config files. will give it a shot on my pi, especially since i’m already running a bunch of monitoring stuff on HA anyway. curious if anyone’s tried it with bigger drives or if there’s any weirdness with permissions?
Good news: this device-swap problem is already solved in v3.0.33+. Simple NAS now stores mounts using stable /dev/disk/by-id/… identifiers (based on the drive’s serial) instead of raw /dev/sdX names, so a USB drive is always found correctly after a reboot even if the kernel assigns it a different letter. Existing /dev/sdX entries are auto-migrated to by-id paths on startup (v3.0.34).
Please update to the latest version. After updating, restart the add-on once with all drives connected so the migration can resolve every drive’s by-id path (if a drive is disconnected during migration, its old raw path can’t be converted).
If you still see swaps after that, please post the output of:
A rare edge case is two identical USB enclosures that report no unique serial number — then their by-id paths aren’t distinguishable. If that’s your setup, let me know and we can switch those mounts to /dev/disk/by-path/ (stable per physical USB port) instead.
I tested hd-idle (1.22-r7) in SimpleNAS 3.1.11 and in my particular case, using an external USB drive (Fantom 2TB GF3B2000UP), this fails…, but works if the “-c ata” argument is passed to hd-idle. I think this parameter is per device, and I’m not sure if this is something that can be determined programatically (?), but I modified your file hd_idle_args.py Line #55 to: args.append(f"-a {disk} -i {IDLE} -c ata") and this works for this particular drive.
Wow this might be something i want, cause i want a hdd to be detectable through the network for storing files..
IS it fast enough? Not for streaming but storing files, like word, pdf, excel etc…
Does it take much resources of ram and storage? (the addon)?
Hi, i installed this, looking promising.
Question, i used the samba addon before so i could browse my files on a windows pc with explorer.
Now i disabled the samba addon and are using this addon.
Is it possible, cause i see my HA config files through files… but is it possible to also share that so i can browse the config files using my windows explorer, instead of going through the addon? @gregorwolf1973
@skank - Yes, the apps appear to be maintained: GitHub shows last updates to Samba Share were 4 days ago; Simple NAS most recent updates were 2 weeks ago. As with most volunteer-maintained open-source community projects, immediate responses to user queries aren’t necessarily expected (and not necessarily from the lead maintainer).
I think I can answer your question, even though I haven’t used the Simple NAS app yet (but am planning to do so soon). And I do use the Samba Share.
From my reading of the docs, it seems that Samba Share provides file-share access to HA disk (like config files), while Simple NAS gives access to disks that are externally mounted to HA server – usually meaning USB-attached drives (thumb drives, external hard disk, etc.).
Since both apps are providing Samba (SMB/CIFS) protocol services to clients, if you want to have both active at the same time, the docs say you need to configure Simple NAS to operate on a different port, and include that port number in your UNC references from Windows, such as: \\my-ha-server-ip:4445\my-share-name
But hmm, for my usage (seldom accessing HA internal files from Windows), it could be simplest to not worry about port #'s, & not have to mess with ports. Then just have both apps installed, & only ever have one of them in Started condition at a time. (Thus only one app ever responding to file-share requests on SMB port 445.) Slightly more tweaky, but probably easier for me to remember than adding a port number to my UNC’s. Not applicable if using fully-automated scripts and such, but maybe OK for my manual activities.
I know i can start/stop whenever i want to avoid conflict.
Thats not the question.
The question is, inside simple nas i can see my files of HA like my config files, however, is there a way to show/map them like the other drives so i can see them through my explorer without going into the addon
Yes, the veto files function works, but I think it currently causes an unexpected issue for macOS users.
I’m using Simple NAS from a Mac, and I noticed that I can copy individual files to the NAS without any problems, but Finder fails whenever I try to copy a folder containing .DS_Store. It immediately returns error -8062.
I tested this with a folder containing only a single .DS_Store and confirmed that removing .DS_Store makes the exact same folder copy successfully. New folders that have never been opened by Finder also copy correctly until macOS creates .DS_Store in them.
From what I understand, this is because veto files makes Samba reject the .DS_Store file entirely. Finder then treats the rejected metadata file as a failed folder copy, so the whole folder operation fails.
Would it be possible to make the veto files functionality optional, for example with a configuration switch? Ideally, users could choose whether these files should be blocked, or they could simply be automatically deleted/cleaned after upload instead of causing the entire folder transfer to fail.
This would be especially useful for macOS users, because currently the feature effectively prevents us from uploading many existing folders at all. I think making it optional would preserve the current behavior for users who want it while allowing macOS users to copy folders normally.
Thanks for adding the feature in the first place — it does work, perhaps just a little too well in this particular case!
I just wanted to say thanks. The add-on is exactly what I was looking for. Unfortunately, it took a while before I stumbled upon it while browsing the web. It really ought to be in the official repository.
on GitHub would be much appreciated!
but yes, it is possible