Network and Storage Protocols
Network and Storage Protocols
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
Solved! See The Solution
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.
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.