NFS Server - RHCSA v9 Review

[@Vegginald]

Super easy to understand. I have been studying for RHCSA for about 3 months and completed Sander's book a couple days ago. After taking his practice exam, my weak points were NFS and containers (I skimmed the containers portion as his explanation was not very good). Thank you for making these videos! They were suggested to me by a guy on facebook.

[@williamjackson1799]

love the content. do you provide 1 on 1 tutoring for the exam

[@samuelalbershtein3122]

Hey beanologi, I did all the steps with the users and groups. However, i'm not able to access the fun directory on both machines (Permission denied) -admin included in group fun. -fun is set to nobody:fun (Same with auto direct) Maybe i should put the no_root_squash entry in /etc/exports ? *Is it mandatory to add .labnet in /etc/fstab ?

[@beanologi]

Hi there, Things to check: - Is your fun group GID identical on both machines? - Did you follow the steps shown at 5:30 in the video? I apologize for the misordered steps but in this one we go back to correct the permissions issues at that point. I left it that way to show a learning process. Basically you need to add write permission and make sure your current shell session is respecting the new group membership (which will take effect in a new login shell). - no_root_squash typically should not be used unless you're debugging as there are security loopholes it introduces. - It is not mandatory to add the .labnet suffix, the DNS server will be able to figure it out and the default search domain set by DHCP in resolv.conf will auto-append .labnet to local hostname lookups anyway. If I take your question literally: as in your admin user is not able access the fun dir (like you cannot `cd` into that dir and you get permission denied) then that means the directory is missing execute permissions for group. This is not likely though as the default umask would ensure that new dirs created are enumeratable by default. Overall it is suggested to check your directory permissions on the NFS server hosting machine. You can use stuff like no_root_squash and chmod 777 /srv/nfs/fun for debugging and isolating the issue but strive to get it working with as few permissions and privileges as possible.

[@samuelalbershtein3122]

@@beanologi Thanks for the valuable tips. I’ll try to fix it :)

[@superduperdonke]

I had to allow rpc-bind and mountd in the firewall before my client(s) could connect to the NFS share

[@beanologi]

I’m glad you got your NFS share working. I am wondering if you were using the showmount utility to check the exports on the server because that is an NFSv3 feature and there isn’t a direct equivalent for NFSv4. In the case you want to use showmount, it is necessary to enable the firewall services you mentioned. Thanks for sharing your experience!

[@superduperdonke]

Ah, that makes sense now. Thanks for the explanation. I was indeed able to verify that clients can connect to the NFS share without the additional firewall changes, but the showmount utility cannot connect (unless I open up the firewall as mentioned above).

[@praveenchandra3327]

@@superduperdonke Yep, the showmount -e command requires both rpc-bind and mountd to work through the firewall on the server side.

[@NamigKaralov]

@@praveenchandra3327 Hello, why are we adding rpc-bindi to firewall?

[@akibhasan737]

when nfs client creates a file inside "fun" directory, it's working and also writeable but the permission of the file for the group is only "r" instaed of "rw".

[@beanologi]

Yes, great observation. This is likely due to the default umask that is used to set perms on new files. A way to work around this would be to use ACLs to enforce more fine grained rules.