We are running SMO 3.3 and snapdrive 5.2 on AIX over NFS
We get problems when SMO is trying to mount a backup and the problem is the snapdrive is trying
to connect the clone over the public interface on the server and this is not in the export list on the filer.
The filer interfaces are:
sc20atc2648-st storage net interface
sc20atc2648 public interface
The server interfaces are:
10.209.2.27 storage net interface
10.208.0.92 public interface
Even if the snapdrive command uses the sc20atc2648-st as filer name the
NFS mount request comes from the public server interface 10.208.0.92.
We have set the mgmtpath and data path with
snapdrive config set –mgmtpath sc20atc2648 sc20atc2648-st
But still get this error:
# snapdrive snap connect -fs /oracle/base/T1SMONFS/data01 /mnt -snapname
to filer directory: sc20atc2648-st:/vol/n2648038_0/T1SMONFS_data01
Volume copy sc20atc2648-st:/vol/n2648038_0 ... created
Cleaning up ...
empty snapdrive-generated flexclone sc20atc2648-st:/vol/n2648038_0 ... done
Info: Host interface 10.208.0.92 can see storage system sc20atc2648-st,
but has no
NFS permission to directory /vol/n2648038/T1SMONFS_data01.
If this is intentional (examples: your routing setup will only use allowed interfaces;
the directories are mounted with the read-only option; etc.), you may safely
ignore this warning.
we suggest verifying NFS permissions on the storage system to avoid any potential I/O errors.
Command error: mount failed: mount: access denied for
mount: giving up on:
Can you check the variable "ping-interfaces-with-same-octet" in snapdrive.conf file. Please set it to "off" and then retry the operation. If this variable is set to on, SnapDrive will consider IPs of the filer's mgmt subnet only..
If this didnt help either, can you upload the logs for the failed operation. This would help to investigate further on this.