TomEA
asked on
Permissions Error Accessing NFS Shares on NetApp StoreVault S500 Server
Hey folks,
We're trying to use a NetApp StoreVault S500 as a storage location for backups of a MySQL database using Zmanda's ZRM for MySQL Enterprise. Both the database server and the backup server are running Ubuntu Linux 9.10 (Karmic). The StoreVault is, of course, running NetApp's proprietary Data ONTAP software.
We have exported a directory on the StoreVault in /vol/exports as an NFS share, and have mounted the share on the backup server. Both the 'mysql' user and the 'root' user must access this share at times during the backup process, and must do so both from the backup server and the database server. The 'mysql' user successfully creates a new directory for a backup, but then runs a command in that directory with sudo. The command fails because, for some reason, the 'root' user does not have access to the directory 'mysql' created! We tried the options for security in the Manage Exports dialog of the StoreVault Manager software to attempt to give all users from that host access as 'root', but that did not help matters.
I am attaching the contents of our /vol/vol0/etc/exports file on the StoreVault, which I believe shows the permissions.
Can anyone offer advice? Where are we going wrong? The support technicians at Zmanda are convinced that it is a permissions error on the StoreVault side, but can offer no solution.
Thanks,
Tom
We're trying to use a NetApp StoreVault S500 as a storage location for backups of a MySQL database using Zmanda's ZRM for MySQL Enterprise. Both the database server and the backup server are running Ubuntu Linux 9.10 (Karmic). The StoreVault is, of course, running NetApp's proprietary Data ONTAP software.
We have exported a directory on the StoreVault in /vol/exports as an NFS share, and have mounted the share on the backup server. Both the 'mysql' user and the 'root' user must access this share at times during the backup process, and must do so both from the backup server and the database server. The 'mysql' user successfully creates a new directory for a backup, but then runs a command in that directory with sudo. The command fails because, for some reason, the 'root' user does not have access to the directory 'mysql' created! We tried the options for security in the Manage Exports dialog of the StoreVault Manager software to attempt to give all users from that host access as 'root', but that did not help matters.
I am attaching the contents of our /vol/vol0/etc/exports file on the StoreVault, which I believe shows the permissions.
Can anyone offer advice? Where are we going wrong? The support technicians at Zmanda are convinced that it is a permissions error on the StoreVault side, but can offer no solution.
Thanks,
Tom
#Auto-generated by setup Sun Mar 14 01:04:16 GMT 2010
/vol/vol0 -sec=sys,rw,anon=0,nosuid
/vol/vol0/home -sec=sys,rw,nosuid
/vol/shares -sec=sys,rw,nosuid
/vol/exports -sec=sys,rw,nosuid
/vol/exports/replica/DB_Backups -sec=sys,rw,root=zrm_server.MYDOMAIN.local:db1.MYDOMAIN.local:db2.MYDOMAIN.local:db1:db2:zrm_server:192.168.3.207:192.168.3.208:192.168.3.90,anon=0
oh and you need to umount an remount the nfs share on the client too after each change you make.
ASKER
1. I am not certain exactly how this works on the StoreVault units, but I'm attaching the output of a 'qtree status' command entered at the console prompt. Perhaps that will give you the answer you're looking for?
2. The line in question is all the machines that have been granted access. They are listed three times, first by fully qualified domain name (FQDN), then by machine name only, and then by IP address. That is the format we have seen recommended.
3. Yes.
And, yes, we have unmounted and remounted
2. The line in question is all the machines that have been granted access. They are listed three times, first by fully qualified domain name (FQDN), then by machine name only, and then by IP address. That is the format we have seen recommended.
3. Yes.
And, yes, we have unmounted and remounted
ASKER
Okay, now I'm -really- attaching the output of the 'qtree status' command. :)
Volume Tree Style Oplocks Status
-------- -------- ----- -------- ---------
vol0 unix enabled normal
shares ntfs enabled normal
shares replica ntfs enabled normal
exports unix enabled normal
exports replica unix enabled normal
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
1. Is the /vol/exports and/or /vol/exports/replica an nfs-style qtree or is it set to NFTS ?
2. could you try replacing the *.MYDOMAIN.local names by the ip adresses ?
3. did you export the nfs filesystem after making any changes ?