I'm facing a perplexing issue with my NFSv4 setup. I have a NAS that serves a directory at /mnt/storage to a Server. There's a user, gitea:gitea (UID/GID 5203), on both systems, and the 'admin' user is part of the gitea group. The permissions are set up like this: /mnt/storage/ has permissions of 775 owned by admin:admin, /mnt/storage/a.txt is set to 664 owned by gitea:gitea, and /mnt/storage/gitea/ has 775 permissions with group gitea (setgid). The weird part is that both admins can read and write to a.txt without issues, but they cannot create new files in the gitea directory. Why is this happening, and is there something I'm missing?
2 Answers
It sounds like the permissions on the /mnt/storage/gitea/ directory are 775 with gitea:gitea ownership, which means only that group can write there. Since 'admin' is not a member of 'gitea' in that context, they're treated as "others" with no permissions to create files. You could do one of these: 1) Add the admin users to the gitea group. 2) Lower the permissions for "others" (though this could pose a security risk). 3) Set an ACL for the directory to give the necessary permissions. 4) Change the directory ownership to either admin:gitea or gitea:admin, which might be the simplest fix here, depending on your setup. Also, make sure to check your group memberships with `getent group admin` and `getent group gitea`. It's odd that admins can edit a.txt though; that's what makes this confusing!
Have you verified that the UIDs and GIDs are consistent between the NAS and the Server? Check if that matches up correctly. Also, it would help to know the exact error message admin gets when trying to create a file in /mnt/storage/gitea. You might want to check local logs on both machines around the time of the error. Just a hunch, but these steps could give you some insights into what's going wrong.
Yes, they do match! Both the "admin" and "gitea" user IDs are consistent. The error when trying to create a file is "Permission denied". It’s puzzling since the error doesn’t appear in journalctl either. I’ll keep checking the logs for more clues.
Yeah, it's baffling! Admin being part of the gitea group is a curveball, especially since they can access a.txt. Seems like option 4 could clear this up for you if the group checks don’t do the trick.