If you’re not using some sort of Domain mapping, then the use of the same mount by two different sharing services with different uids is going to break ownership. Doesn’t matter if it’s Synology or anything else.
NFSv4 domain mapping solves this by having the same domain configured in client and server. That’s probably your simplest option. From memory, I do believe Synology DOES set uid for whichever user is authenticated via SMB and NFS though, so are you using two different users for these mounts by chance?
If you don’t want to bother to setup LDAP or domain mapping, then just use SMB and that should solve the problem.
Yeah which frankly gets annoying fast when dealing with multiple users. As you need to remember the UIDs of all the users and match them potentially on all systems.
A solution to this problem is using active directory or if it is only for Linux devices FreeIPA. Which isn’t as bad as it sounds. It even simplifies it if you ask me. More centralized management. It is a onetime effort to setup correctly then just keeping it in check.
Please just use Kerberos instead of fiddling with uids. It’s the only sane way to get NFS access controls and user mapping. Works on both Linux and macOS (but there’s no NFS on Windows anyway).
I’d say you can run the Kerberos KDC on the NAS but if Synology has some locked down special OS you’ll need another machine for that (edit: but you say you have other servers already so that shouldn’t be a problem).
Unfortunately SMB is so screwed that you can’t reuse ordinary Kerberos for authentication there, which is unfortunate if you want to have both that and NFS. I’ve yet to look into whether Samba AD can be used for both.
There you can create/authenticate user with a central repo in a machine independent fashion. Also having the possibility to allow /egate specific services from the central database is a big plus.
It seems difficult at the very beginning but it quickly pays off. Give it a try
True. I knew I should have left that as “NFS 4” because someone would comment this. From what I’ve read (never used it), NFS 3 is very different to 4 and also just kind of not worth using, especially just for Windows, since it has no security at all.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
If you’re not using some sort of Domain mapping, then the use of the same mount by two different sharing services with different uids is going to break ownership. Doesn’t matter if it’s Synology or anything else.
NFSv4 domain mapping solves this by having the same domain configured in client and server. That’s probably your simplest option. From memory, I do believe Synology DOES set uid for whichever user is authenticated via SMB and NFS though, so are you using two different users for these mounts by chance?
If you don’t want to bother to setup LDAP or domain mapping, then just use SMB and that should solve the problem.
Thanks for the feedback. I plan to do some reading on NFSv4 domain mapping this weekend.
It was over a decade ago when I last looked, but all the ldap/kerberos stuff put me right off NFSv4.
You need to set the permissions on the NAS to match up with the ID of your user.
Yeah which frankly gets annoying fast when dealing with multiple users. As you need to remember the UIDs of all the users and match them potentially on all systems.
A solution to this problem is using active directory or if it is only for Linux devices FreeIPA. Which isn’t as bad as it sounds. It even simplifies it if you ask me. More centralized management. It is a onetime effort to setup correctly then just keeping it in check.
Yeah, Synology and NFSv4 is a bit hit or miss if you don’t use a Kerberos server. I’ve experimented with that back in 2018 to no avail: https://blog.mbirth.uk/2018/01/05/synology-nfsv4-with-id-mapping.html
Please just use Kerberos instead of fiddling with uids. It’s the only sane way to get NFS access controls and user mapping. Works on both Linux and macOS (but there’s no NFS on Windows anyway).
I’d say you can run the Kerberos KDC on the NAS but if Synology has some locked down special OS you’ll need another machine for that (edit: but you say you have other servers already so that shouldn’t be a problem).
Unfortunately SMB is so screwed that you can’t reuse ordinary Kerberos for authentication there, which is unfortunate if you want to have both that and NFS. I’ve yet to look into whether Samba AD can be used for both.
I would recommend an LDAP sever for user Auth.
There you can create/authenticate user with a central repo in a machine independent fashion. Also having the possibility to allow /egate specific services from the central database is a big plus.
It seems difficult at the very beginning but it quickly pays off. Give it a try
There is, although only the client and only v3 support.
True. I knew I should have left that as “NFS 4” because someone would comment this. From what I’ve read (never used it), NFS 3 is very different to 4 and also just kind of not worth using, especially just for Windows, since it has no security at all.
It’s enough if you just need access in a VM or over a lan (depending on your threat model) but agreed.