Network and Storage Protocols

NFS default permission

VEERENDRA84
26,821 Views

Hi,

 

I am new netapp. Pls help me clarify my doubt

 

I create a volume with the name testvol on my filer node3

 

I export the volume using the command rsh node3 exportfs -v /vol/testvol

 

If I do rsh node3 exportfs | grep -i testvol I get below output

 

/vol/testvool -sec=sys,rw

 

As per my knowledge when I export a volume like this it should be writeable by all nfs clients

 

I mount the volume on a clinet on a dir /test

 

After  I mount the volume on the client if I do cd /test and do touch 1 it says perm denied. According to me it should not show perm denied since the volume is global rw.

 

Pls let me know why it shows perm denied

 

Thanks in advance

Veerendra

 

 

1 ACCEPTED SOLUTION

parisi
26,764 Views

What are the file permissions on the volume?

 

If they are anything 5 or lower, then you are only getting read access based on the export. Since you have not defined a root client, you might be getting squashed to the anon user, which falls into a different mode bit permission set than the owner, unless that owner is anon.

 

For example, my export looks like this:

 

/vol/nfs        -sec=sys,rw,nosuid

 

The file permissions:

 

filer> fsecurity show /vol/nfs
[/vol/nfs - Directory (inum 64)]
  Security style: Unix
  Effective style: Unix

  DOS attributes: 0x0010 (----D---)

  Unix security:
    uid: 0
    gid: 0
    mode: 0777 (rwxrwxrwx)

  No security descriptor available.

 

With those permissions, I can write:

 

[root@centos64 /]# mount | grep /vol/nfs
10.63.9.69:/vol/nfs on /7mode type nfs (rw,nfsvers=3,addr=10.63.9.69)
[root@centos64 /]# cd /7mode
[root@centos64 7mode]# touch newfile

 

But notice who the owner is...
[root@centos64 7mode]# ls -la | grep newfile
-rw-r--r--.  1 nfsnobody nfsnobody     21 Jan 14  2015 newfile
[root@centos64 7mode]# ls -lan | grep newfile
-rw-r--r--.  1   65534 65534     21 Jan 14  2015 newfile

 

This is despite me being root:

 

[root@centos64 7mode]# id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

 

I also can't chmod, as the system doesn't think I am root:

 

[root@centos64 /]# chmod 755 7mode
chmod: changing permissions of `7mode': Operation not permitted

 

When I add root to the export, I can chmod.

 

/vol/nfs        -sec=sys,rw,root=10.228.225.140,nosuid

 

[root@centos64 /]# chmod 755 7mode

[root@centos64 /]# ls -la | grep 7mode
drwxr-xr-x.   6 root root       4096 Oct  7 23:59 7mode

 

When I change the export back to rw, root cannot write (just like in your scenario):

 

/vol/nfs        -sec=sys,rw,nosuid

 

[root@centos64 7mode]# touch noroot
touch: cannot touch `noroot': Permission denied

 

Think of exports as share permissions in Windows and mode bits as ACLs in Windows. In a CIFS environment, if your share allows you full control, you can still get denied access if the ACL denies you.

 

Users must authenticate to prove who they are to the storage and then once authenticated, the permissions will determine true access.

 

You have two options:

 

1) Open file permissions up to more users/groups

2) Add root= to your exports.

View solution in original post

1 REPLY 1

parisi
26,765 Views

What are the file permissions on the volume?

 

If they are anything 5 or lower, then you are only getting read access based on the export. Since you have not defined a root client, you might be getting squashed to the anon user, which falls into a different mode bit permission set than the owner, unless that owner is anon.

 

For example, my export looks like this:

 

/vol/nfs        -sec=sys,rw,nosuid

 

The file permissions:

 

filer> fsecurity show /vol/nfs
[/vol/nfs - Directory (inum 64)]
  Security style: Unix
  Effective style: Unix

  DOS attributes: 0x0010 (----D---)

  Unix security:
    uid: 0
    gid: 0
    mode: 0777 (rwxrwxrwx)

  No security descriptor available.

 

With those permissions, I can write:

 

[root@centos64 /]# mount | grep /vol/nfs
10.63.9.69:/vol/nfs on /7mode type nfs (rw,nfsvers=3,addr=10.63.9.69)
[root@centos64 /]# cd /7mode
[root@centos64 7mode]# touch newfile

 

But notice who the owner is...
[root@centos64 7mode]# ls -la | grep newfile
-rw-r--r--.  1 nfsnobody nfsnobody     21 Jan 14  2015 newfile
[root@centos64 7mode]# ls -lan | grep newfile
-rw-r--r--.  1   65534 65534     21 Jan 14  2015 newfile

 

This is despite me being root:

 

[root@centos64 7mode]# id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

 

I also can't chmod, as the system doesn't think I am root:

 

[root@centos64 /]# chmod 755 7mode
chmod: changing permissions of `7mode': Operation not permitted

 

When I add root to the export, I can chmod.

 

/vol/nfs        -sec=sys,rw,root=10.228.225.140,nosuid

 

[root@centos64 /]# chmod 755 7mode

[root@centos64 /]# ls -la | grep 7mode
drwxr-xr-x.   6 root root       4096 Oct  7 23:59 7mode

 

When I change the export back to rw, root cannot write (just like in your scenario):

 

/vol/nfs        -sec=sys,rw,nosuid

 

[root@centos64 7mode]# touch noroot
touch: cannot touch `noroot': Permission denied

 

Think of exports as share permissions in Windows and mode bits as ACLs in Windows. In a CIFS environment, if your share allows you full control, you can still get denied access if the ACL denies you.

 

Users must authenticate to prove who they are to the storage and then once authenticated, the permissions will determine true access.

 

You have two options:

 

1) Open file permissions up to more users/groups

2) Add root= to your exports.

Public