NFS filesystem without write permission

[Toscano]

Hi all,

I am sharing a filesystem by NFS from an HP-UX 11.31 server (PR1) to an HP-UX 11.31 client (beta16) and when mounting the share it does not allow me to write.

What did I do on the NFS server?

1.- NFS configuration in file /etc/dfs/dfstab
PR1>#cat /etc/dfs/dfstab
# place share(1M) commands here for automatic execution
# on entering init state 3.
#
# share [-F fstype] [ -o options] [-d "<text>"] <pathname>
# .e.g,
# share -F nfs -o rw=engineering -d "home dirs" /home
share -F nfs -o rw=beta16 /NFS-prueba

2.- Share and validate the NFS filesystem
PR1>#exportfs -av
PR1>#share
- /NFS-prueba rw=beta16,ro= ""

3.- I validated the permissions and did a write test on the NFS filesystem
PR1>#ll
total 5114
drwxrwxrwx 2 sybasen sybase 8192 Jan 19 11:26 NFS-prueba
PR1>#cd /NFS-prueba
PR1>#touch file1
PR1>#ll
total 0
-rw-r--r-- 1 root sys 0 Jan 19 11:25 file1

What did I do on the NFS client?

1.- On the NFS client I checked and mounted the shared filesystem
beta16>#showmount -e pr1
export list for pr1:
/NFS-prueba beta16
beta16>#mount pr1:/NFS-prueba /NFS-prueba
beta16>#cd /NFS-prueba
beta16>#ll
total 0
-rw-r--r-- 1 root sys 0 Jan 19 12:25 file1

2.- When performing a write test on the NFS client the process fails due to write permissions
beta16>#touch file2
touch: file2 cannot create
beta16>#
beta16>#rm file1
file1: 644 mode ? (y/n) y
rm: file1 not removed. Read-only file system

If the NFS server statement (share -F nfs -o rw=beta16 /NFS-prueba) gives write permission to NFS filesystem, why doesn't the NFS client allow writing?
Could someone help me?

[Bertram Stoeckler]

>>beta16>#rm file1
>>file1: 644 mode ? (y/n) y
>>rm: file1 not removed. Read-only file system

There are a couple of possible reasons.

The most common one is the missing "root=..." export.

If you are "root" at the NFS-client, then you will need to explicitly add a "root=<NFS-client>" to the share.

The error-message "Read-only file system" may be an idication that:

1. your server-filesystem is indeed mounted read-only. Check the "mount -a" output at the server.

2. you use NFSv4, and the client was only allowed to mount the pseudo-filesystem, which by default is read-only. That´s happening if the root-export is missing.

3, You are using NFSv4 and the NFSv4-id-mapping is not done correctly.

So next steps are:

1. Check the share-manpage and add, in addition to the rw-list a "root" list.

2. Check if you mount with NFSv4, (nfsstat -m at the clien will tell you)

3. If adding root does not fix the problem, check that the hostname in the share-list can be resolved to an IP-address in both direction. Use FQDN if possible, or IP-addresses.

4. try NFSv3 instead of NFSv4, or vice versa

Hope that helps!

[KishJ]

Greetings,

The command used on PR1, the NFS server to export the FS:
        
share -F nfs -o rw=beta16 /NFS-prueba

The specific permission option used:

-o re=beta16

Here beta16 is the access_list and is likely the hostname of the client. If yes, it is very important that this name gets resolved successfully on PR1.

Please check what service is being used for hostname resolution

# cat /etc/nsswitch.conf

If "hosts" is set to files (preferred) then you need to ensure /etc/hosts file has an entry for "beta16" 

If "hosts" is set to DNS or NIS etc. please add FQDN of "beta16" 

If /etc/nsswitch.conf is not configured, please configure create this file by copying /etc/nsswitch.files

Hope it helps. Please let me know if the issue persists.         

[KishJ]

I am sorry for the typo. "-o re" is actuall "-o rw" the rest of the content still holds good. 

[Toscano]

Bertram, thanks for your answer.

This is the NFS client version
beta16>#nfsstat -m
/NFS-prueba from pr1:/NFS-prueba
Flags: vers=3,proto=tcp,sec=sys,hard,intr,link,symlink,acl,devs,rsize=32768,wsize=32768,retrans=5,timeo=600
Attr cache: acregmin=3,acregmax=60,acdirmin=30,acdirmax=60

By correcting the line "share -F nfs -o root=beta16 /NFS-prueba" in the /etc/dfs/dfstab file, the write permission problem for the shared filesystem was solved

Now from the NFS client, I performed successful write tests with root and sybasen users, being as shown below:
beta16>#ll /NFS-prueba
total 0
-rw-r--r-- 1 root sys 0 Jan 19 12:25 file1
-rw-r--r-- 1 nobody sys 0 Jan 21 11:09 file2
-rw-r--r-- 1 sybasen sybase 0 Jan 21 11:22 file3

Now I have another problem, the filesystem can be mounted from all servers on the network, when it should be only available to mount from beta16.

for example for this other server, I can mount the filesystem and modify the files. this is incorrect.
PR2>#pwd
/NFS-prueba
PR2>#touch file-fromPR2
PR2>#ll
total 0
-rw-r--r-- 1 nobody sys 0 Jan 21 10:38 file-fromPR2
-rw-r--r-- 1 root sys 0 Jan 19 11:25 file1
-rw-r--r-- 1 nobody sys 0 Jan 21 10:09 file2
-rw-r--r-- 1 sybasen sybase 0 Jan 21 10:22 file3
PR2>#

How can I limit the access of other servers to the NFS filesystem?

[Bertram Stoeckler]

I know the man-page can be confusing....

Some details;

The share-command maintains 3 access-lists, with specific defaults, if not specified.

1. a "rw" list (read-write)

2. a "ro" list (read-only)

3. a "root" list

If you do not specify any option then the share-comman will use the following defaults:

- "read-write" to any client, and NO root-access. So any client is put on the "rw" list, "root" list is empty.

If you explicitly add a "rw" list ( -o rw=host1,host2), then any client on the "rw" list will be allowed read-write access. All other clients will implicitly be added to the "ro" list, So read-only (still able to mount).

If you explicitly add a "ro" list ( -o ro=host3,host4), then any client on the "ro" list will be allowed read-access. All other clients won´t be allowed to mount !!

The root-list is independent from the rw-list and ro-list. It only controls which clients are allowed to do operations as "root".

In your case, to disable access for the other clients, you will need to

1. add your system to the read-write ("rw")-list.  

2. add an empty read-only ("ro") list:

E.g: share -F nfs -o root=beta16,rw=beta16,ro= /NFS-prueba 

Note there is a blank-character between "ro=" and /NFS-prueba.

 Let me know if that fixes your problem.

[Toscano]

Hi,

I made the suggested change in the /etc/dfs/dfstab file
share -F nfs -o root=beta16,rw=beta16,ro= /NFS-prueba

From the NFS client, I can see that the access permissions of the /NFS-prueba have changed from (everyone) to (beta16), that's OK.
beta16>#showmount -e pr1
export list for pr1:
/NFS-prueba beta16

Again when I mount /NFS-test on the NFS client, the write permissions are lost
beta16>#cd /NFS-prueba
beta16>#touch file4
touch: file4 cannot create

If I verified from another server on the network, I can mount  /NFS-test on other server, which is not correct
PR2>#mount pr1:/NFS-prueba /NFS-prueba
PR2>#bdf | grep /NFS-prueba
pr1:/NFS-prueba 1376256 815528 556448 59% /NFS-prueba

[KishJ]

Please try to stop and restart both NFS client and server and then check again.

[Bertram Stoeckler]

- How does the hostname "beta16" get resolved to an IP address?

- Do you have a DNS server configured? 

At the NFS-server, check with "nslookup" that both the hostname "beta16" gets resolved to the clients, valid IP-address, and vice-versa, that the IP-address gets resolved to the "beta16" name. Especially the 2nd case is important as the server will pickup the sender-ip address out of the network-packet, then resolve it to a hostname, and then search for a match in the share information. If the revers lookup using the client-ip-address returns a FQDN (full qualified domain name), then use the FQDN name in your share command. 

Is the NFS-client having multiple network interfaces with multiple ip-addresses? (multi-homed-host)

If yes, then add all IP-addresses/Hostnames to the list of shared-system.

Since the first-suggested syntax, without the rw-list and empty ro-list allowed you to create a file, try using different share syntaxes. Try with and without the "rw", or "ro" statement. 

With all test, make sure that you do NOT mount with NFSv4, as otherwise you could get impacted by misconfigured NFSv4idmapping.

If all that does not help, then you should open a support-case.

Hope that helps.

[Bertram Stoeckler]

I read the man-page again:

The "ro" access-list overides the "rw"-list. That would mean that my suggested order of the options could be wrong. 

Instead of:

share -F nfs -o root=beta16,rw=beta16,ro= /NFS-prueba

try:

share -F nfs -o ro=,root=beta16,rw=beta16 /NFS-prueba

Let me know if that works.

[KishJ]

Greetings,

The following syntax may also work:

share -F nfs -o root=beta16,rw=beta16 /NFS-prueba

Please test and let us know.

[KishJ]

Hope the syntax worked for you. It would be good if you could confirm or let us know if the issue persists.

[Toscano · Accepted solution]

Thanks all for your participation and support.

I have done all the possible combinations with the syntaxes given and I always get the same result (No Write permission).

The only syntax that worked is: share -F nfs -o root=beta16 /NFS-prueba, but this is open for everyone.

I am going to close this query, again thanks.
Toscano

[Bertram Stoeckler]

While the problem has been marked as solved, i am adding the correct solution to this issue after i got access to some old HPUX boxes.

In my previous statements i suggested to add an empty read-only list via the "ro=" option. This is correct, but the syntax is wrong. The "ro=" syntax adds a read-only list for any client that is not in the read-write-list.

 There a 2 ways to get the desired behavior:

A) share -F nfs -o root=beta16,rw=beta16,ro=dummy /NFS-prueba

B) share -F nfs -o sec=sys, root=beta16,rw=beta16 /NFS-prueba