I am having ACL conflicts on my homelab

Hey guys, so I have three directories that are the topic of this thread:

  1. /home/jellyfin/media/Videos/Movies
  2. /home/jellyfin/media/Videos/TV
  3. /home/syncthing/Music

So this directory structure seems pretty self-explanatory, I feel; but I have created home users for each specific service that I run on my homelab. I then have bind mounts that bind each directory in a respective location at srv/nfs. (Although, it would probably be best if I switched the Music directory to a link since its locations are on the same drive, albeit different partitions. Plus I may want to share the Music directory with the Jellyfin user later on. Should I use a soft link or a hard link though?) The directories are owned by their home user, but they are the group of the user group that I use on all of my systems. The problem is that I cannot get permissions sorted. I need it to allow the nfs service to serve the content over my local network so that I have an easy way to access current content from my Linux machines and sore new content. Music is synced , using Syncthing, to my phone, but my Linux machines must rely on NFS because I don’t want them taking up space on my desktops and laptop. Perhaps, I should create a media group (if it doesn’t already exist) and use that on all of the relevant users. I wish NFS had a more robust permissions system, or I knew how to set up user mapping better. What should I possibly do to where I can get all of these users the right permissions.

P.S. It is really late here, so I am going to post this, and fix any mistakes in the morning when I wake up.

honestly you would be better off creating a ‘media’ USER and doing everything media related through that, as apposed to even trying to assign a shared group to all of your media accounts.

NFS does not have ANY permission system, it is simply a network connection to the in place system (that has to function correctly to begin with)

lets not even delve into hard vs soft linking until the other things are sorted out.

Yeah it just passes through the user and group to the client. I think I was unclear with my initial question. I am aware that the NFS server service itself doesn’t run as a user or group. Also, according to the Arch Wiki, there is a way to map UIDs and GIDs on the server to client-side uids and gids. My problem was with uids and gids on my server not matching with NFS clients.

To clarify, my question wasn’t a how or why question, but rather it was a which way should I go. To be honest, I forgot about this forum post because I already figured out which way I wanted to do things. I simply mounted the filesystem to the /home/jellyfin/media directory instead of the /srv/nfs directory. Then I bind mounted the subdirectories within the /home/jellyfin/media directory to their respective places within the /srv/nfs directory. Basically, I did a reversal of my previous method of doing things. Secondly, I created a media group with gid 615 because it seems unlikely that any of my systems have a group with that gid in use already. I added the jellyfin user to the new group as well as the directory owner for extra brownie points. Finally, I recursively changed the owner and group of the NFS directories to the uid:gid of 1000:615 respectively. I modified the permissions to be 755 on directories and 664 on files. Side note, I have honestly never understood how the ACL lists work on directories within Linux. How can I give read and write permissions on a directory to a group, but then the user within that group cannot cd into it. That seems like a read permission to me, but perhaps it is in fact an execute permission.

Now the only remaining task is to create the media group with gid 615 and add my user to it for each NFS client that I want to connect to the NFS storage. The first user created by seemingly every distro has a uid of 1000 which perfectly maps it to the owner of the directory on the NFS server itself, so it really isn’t necessary to add that user to the group with gid 615 afaik.

Hopefully that wall 'o text makes sense.

P.S., I also found this nifty little article by RedHat about hard links versus soft links. I will say that I had a basic understanding of them before in that soft links just link to the file or directory much like a pointer links to a variable in programming and a hard link is like a copy of the variable, but this helped clear things up quite a lot. I pretty much always only ever used soft links. And now I realize that a bind mount is more like a replacement for hard links on directories since you can’t hard link a directory.