Why allow “everyone” to have read write permission to shared folders in order to run container manager? Wouldn’t this be insecure?
Its not as egregious as you think. ‘Everyone’ group means every Synology user account - not that everyone on the network that can talk to the NAS, they’d still need both a Synology account and Shared folder permissions. Any Synology user trying to access those files would still have to have read and write access to the Share to actually access it (eg via file explorer SMB/CIFs or app-level access to Synology File Manager, or they would need to be granted SSH access to get in via terminal, etc) in order to R/w/m the files.
I know it’s a bit confusing, but it’s correct. Docker often causes confusion with file permissions. There are file-level permissions (this article) and there are share-level permissions. You need both to access folders and files via mapped drives / SMB, this setting is just to ensure that Docker containers which can be running as a variety of user names (depending on how you config docker and the container) don’t experience issues accessing files you’re expecting them to be able to access, as Synology says, the default Docker folder permission is for the ‘everyone’ group to have Read-only access. This should allow most Docker containers configs to at least run and then if you run into issues writing/modifying files… That’s a clue you have missed some file permission configuration settings that need to be done, and the only reason it’s running at all is because that default ‘everyone’ permission is saving your butt.
Thanks this is very helpful
To add to this, SMB implementations on Linux today simply respect the archaic model MS developed for LAN Manager (Windows 3.1, 1980’s), before Windows had local user permissions (NT 3.51 mid 90’s).
MS saw share permissions as a mechanism to provide admins some level of control for the small networks.
Once NT became the standard in business, we started ignoring share permissions and just letting file system permissions manage everything (since that could be managed via domain credentials).
It’s a whole lot easier and more secure to manage Groups in the Domain than a bunch of share permissions, and they’re lots more granular.
So we’re stuck with share permissions though they’re not all that useful - so most people (everyone?) simply ignore them and use just file system perms, which you have to manage even without shares.
TL:DR Share perms are a legacy thing and can simply be set to everyone read/write
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters NAS Network-Attached Storage NFS Network File System, a Unix-based file-sharing protocol known for performance and efficiency SMB Server Message Block protocol for file and printer sharing; Windows-native SSH Secure Shell for remote terminal access SSL Secure Sockets Layer, for transparent encryption
5 acronyms in this thread; the most compressed thread commented on today has 22 acronyms.
[Thread #296 for this comm, first seen 16th May 2026, 07:50] [FAQ] [Full list] [Contact] [Source code]
Good bot
I think it was just an example (poor one, true).
In my case, I just need to give access to my admin account in order for them to work - not the default admin account, to be clear.