Unable to add NFS storage to the Data appliance

[ekrejci]

Hello,

I’m trying to add NFS storage to the data appliance.

I followed the documentation, and when I ran the script supposed to mount/add the NFS storage to the appliance, an error saying that the export is read only, which is actually not the case:

./mount-nfs-store.pl --nfs servername.domain.com:/hzn-data-01

NFS: servername.domain.com:/hzn-data-01

HOST: servername.domain.com

servername.domain.com is alive.

mount.nfs: timeout set for Fri Mar  8 21:33:13 2013

mount.nfs: trying text-based options 'hard,rsize=32768,wsize=32768,intr,addr=128.178.102.59'

mount.nfs: prog 100003, trying vers=3, prot=6

mount.nfs: trying XXX.XXX.XXX.XXX prog 100003 vers 3 prot TCP port 2049

mount.nfs: prog 100005, trying vers=3, prot=17

mount.nfs: trying XXX.XXX.XXX.XXX prog 100005 vers 3 prot UDP port 1234

servername.domain.com:/hzn-data-01 on /opt/zimbra/store10 type nfs (rw,sync,noatime,hard,rsize=32768,wsize=32768,intr)

Error occurred: directory does not exist or is not writable: /opt/zimbra/store10

zmvolume failed at ./mount-nfs-store.pl line 49.

Of course, I tried to go in the mount point (in this case /opt/zimbra/store10) and was totally able to write into it (touch, create file + dir, etc...).

The data appliance has root access to the NFS export. I don’t have any idea about the cause of this error.

Any clue?

Many thanks

Eric

[agawarikar]

can you do me a favor? After mounting, please check if "su - zimbra; cd /opt/zimbra/store*"; touch blah", this will ensure that there is r/w perms for zimbra user on the mount point.

[aarron]

thanks for the reply

what should i see as confirmation that the command has worked?

[agawarikar]

A new file should be created named "blah" by the user "zimbra"

[aarron]

ok

no  - no file called "blah" has been created

[agawarikar]

Then this is a NFS server issue, and you need to enable correct perms.

[admin]

The "Error occurred: directory does not exist or is not writable: /opt/zimbra/store10" is misleading, I opened an internal bug and we are in the process of updating the docs/rel notes.  It's always a NFS server side perms issue indeed.

[aarron]

cheers for all the help

worked it out - using netapp nfs mount, security style on the qtree was "NTFS", set to "UNIX" - all good