I have a shared storage disk mounted to Server A (172.25.130.109). This shared storage is accessible only by one user in the "users" group. I want to mount this shared storage to Server B (172.25.130.104) from Server A using nfs.

This is what I did:-
Server A
1. Edit the /etc/exportfs and added the following:-
The reason for suqashing is because as mentioned, only one user called "admin" can access the storage. However, the UIDs for admin in Server A and Server B is different so I'm squashing and mapping the UID in the nfs client to 900 so that "admin" in Server B can access the folder.

2. Reloaded the directories via "exportfs -vr" command

Server B
1. Created /etc/fstab entry as follow:-
2. Mount the drive as root
3. Switch to "admin" user and attempt to access the directory /ARCHIVE
At this juncture, I get permission denied.

Any idea what I'm doing wrong?

I've googled all over and really not sure what's gone wrong since all the examples I've seen (and followed) is straightforward.

By the way, I'm using RHEL 5.2.

NOTE: I'm aware an easier alternative is to change the Server B "admin" user UID to be inline with Server A, but I'm trying to avoid that.

Greetings,

Well, taking a look at what you have there, let's start with the /etc/exports entry:
Now, does the UID 900 actually exist and is available on the Server A? If not, then change it to something that does exist on Server A that you consider "safe". That is what any new entries will appear to be from on Server A when accessed/written to across the mounted share, which with all_squash is what everything will appear to be.

Also, an example of a couple additional entries in the /etc/exports file that have helped me out in the past:
Now, if you are doing 'ro', then I imagine you don't *need* sync, but you will likely get a warning message if you don't put something. The 'no_subtree_check' will, at the very least, make the mounting of the shared directory faster since it won't require NFS to check the entire filesystem before completing the mount.

Now, on the other side, let's look at the /etc/fstab entry of Server B:
Well, I have never been one for blind "default" settings, so let me show you an example of one of the mounts of one of our servers:
So, I have it that it is readable and writable, that changes must make it to disk before next request is serviced, that the mounting process is left in the background, that the mounting is done automatically when the filesystems in the fstab are processed on boot/startup, that the mounting process is interruptible (should there be an issue with the mounting), and that the mounting client will fail if there isn't success in the 10 minutes of retries.

Also, you don't need the filesystem check settings (e.g. "0 0") at the end of Server B's fstab entry as that should be handled by Server A to begin with.

HTH. Let us know.

I didn't know this! I had thought (misunderstood rather) that the usage of anonuid will just 'map' the current UID ownership of the folder to the specified anonuid at the remote machine, without needing an actual user in the local machine with that UID. Anyway, I've created a user with the UID 900 in the local machine.

I reloaded the /etc/exports. Note that my /etc/exports is still the same as before.

In Server B, I updated the /etc/fstab as follow:-
I did a remount of the folder.

Unfortunately, the ownership is still set as seen in Server A. As such, the "admin" user in Server B (UID=900) is unable to access the folder, whose ownership still belongs to UID=510 (as per Server A). By the way, the folder is set to Owner-only access i.e. 700.

Is there any logs I can and should be looking at?

Moved: This thread is more suitable in Linux Server and has been moved accordingly to help your thread/question get the exposure it deserves.

And on Server A the local UID=900 can access the data?