Birmingham mumbai

subtree checking
, which 
has had some stability issues in the past. Normally, when a directory is exported, 
NFS might scan parent directories as well, which is sometimes problematic, and 
can cause issues when it comes to open file handles.
There are several other options that can be included in an 
export
, and you can read 
more about them by checking the man page for 
export
:
man exports
One option you'll see quite often in the wild is 
no_root_squash
. Normally, the 
root
 
user on one system is mapped to nobody on the other for security reasons. In most 
cases, one system having 
root
 access to another is a bad idea. The 
no_root_squash
 
option disables this, and it allows the 
root
 user on one end to be treated as the 
root
 user on the other. I can't think of a reason, personally, where this would be 
useful (or even recommended), but I have seen this option quite often in the wild, 
so I figured I would bring it up. Again, check the man pages for 
export
 for more 
information on additional options you can pass to your exports.
Next, we have one more file to edit before we can actually seal the deal on our NFS 
setup. The 
/etc/idmapd.conf
 file is necessary for mapping permissions on one node 
to another. In 
Chapter 2
, 
Managing User Permissions
, we talked about the fact that each 
user has an ID (UID) assigned to them. The problem, though, is that from one system 
to another, a user will not typically have the same UID. For example, user 
jdoe
 may 
be UID 
1001
 on server A, but 
1007
 on server B. When it comes to NFS, this greatly 
confuses the situation, because UIDs are used in order to reference permissions. 
Mapping IDs with 
idmapd
 allows this to stay consistent and handles translating each 
user properly, though it must be configured correctly and consistently on each node. 
Basically, as long as you use the same domain name on each server and client and 
configure the 
/etc/idmapd.conf
 file properly on each, you should be fine.

---

Chapter 12