The below situation is just an example. I’m looking for a general resource to learn how to manage permissions on the client side once I’ve shared NFS shares.
I have several datasets I’ve set up with permissions given to a group “mmanager” GID: 1000. I’ve shared these directories via NFS shares. I host a Plex server and mounted these shares. The only way I can use Plex to watch content is if I add an ACL item to give “Full Control” to @everyone. How do I basically tell TrueNAS that my user on the client system is a member of mmanager, and give them permission to access/control the data on the dataset? Am I understanding that this is what I’s “supposed” to do with an NFS share?
I’m more than happy to follow a link and do my own research if someone has a good resource for me.
Can you elaborate a bit? EDIT: I don’t want to manage permissions on the client side I guess. I want to grant permissions to the client “correctly” from the server side. Maybe that’s the better way to phrase it.
Ah OK. So If I modify the mmanager group to be let’s say GID 1010, and add mmanager group 1010 to the root user on the client side, permissions should work then?
Definitely going to take a look at this. For now, I was able to make a group called mmanager GID 1010 on TrueNAS, and make no user owner and GID1010 the group owner for the pools. I shared via NFS, then add the plex user to the mmanager group. Works!
If you look at the documentation, there’s a checkbox in the NFS server config to have rpc.idmapd handle group memberships. That can help work around lack of consistent id configuration for some environments. In this case group membership is resolved server-side rather than relying on the NFS client to describe the groups its a member of. Just FYI.
I’ve spent DAYS trying to understand NFS and it seems madeningly simple and complex at the same time.
I have an Ubuntu server running docker. Root UID is 0 and the UID running most dockers is 1000. I have both root user and user 1000 being in each and every group that has full control for each of the pools in TrueNAS. I’ve messed with each of the seemingly similar NFS options: allow non-root mount, maproot user, maproot group, mapall user, etc to no avail. I’ve literally changed permissions on all my pools to everyone@ has Full control and it still doesn’t work. How is this possible. If the pool is told to give full control to everyone, how is a mount in Ubuntu unable to navigate through the structure? I modified permissions recursively. In Ubuntu the owner and group of files in the root of the share are listed differently than how I’ve made them in TrueNAS.
I tried looking into Kerberos, but there’s literally no good walk-throughs on Youtube. How, with the community as strong and robust as it is, is there not a clear guide for “hey, this is the good accepted way to share data pools in TrueNAS core with docker containers in Ubuntu”? It’s obviously a very common thing to do…
I’m just feeling lost and looking for some support. I’m trying to get my Resilio Sync instance in docker to work with several data pools in TrueNAS. I didn’t think this would be so hard and I’m feeling defeated. Someone please help.
It depends on the context. It’s a normal thing to see if idmapping is broken / not configured between client / server.
KRB5 + NFS4 is more typical in enterprise deployments where systems administrators are familiar with / trained on the relevant technologies. It’s kind of a large step for a hobbiest to get right since the amount you have to learn is rather large and deep. This doesn’t lend itself to a simple checklist-style howto.
Random thought. When configuring users in TrueNAS, there are permissions for the home directory. These directories are the one’s I’m trying to work permissions with. Is it possible that the pool permissions settings and the home directory settings are conflicting with each other?
Also separate question- should it be feasible to grant permissions to a group and then manage them entirely through group permissions? Question another way: is there anything that can only be granted through “owner” that can’t be granted through “group”?
OK, I’m wondering if my permissions issue is stemming from the fact I have these datasets set up as home directories. Here’s the steps I took.
Created pool, created a dataset called “users”, added a sub dataset with the same name as each user for whom it would become the user directory. Then I set up users and groups for each of the my four users and set the home directory to each dataset.
Once the client get’s a file system handle for a mount that mount is permanent even if the server admin removes the client from the exports list and restarts mountd. As long as the client is not rebooted, consequently forgetting the handle, you cannot lock it out after the fact.
When a client issues a command to the server it sends the file system handle it got during the mount and the inode number - just like it would for local access. And that handle is per file system. It’s the vnode kernel layer over the network. Very simple. So it could run on systems in the 1980s.
That’s why that limitation is so fundamental. It’s in the core of NFS’ design. Probably never going to change.
Yeah, I recall there was an old bug / design issue back in the day where you could walk outside the export if you happened to know (or could guess) the inode number, device, and inode generation of a file.
