I had a similar issue on a production system, but it was the "options httpd.admin.enable on" that fixed it for me.
EDIT: I ran into this again on a re-installation and reconfiguration run, and discovered an old export from a previous test run laying around that it was attempting to remount. Once I cleaned up the /etc/exports and did a "exportfs -a" it went fine.
I'm not sure if you found a permanent response to this, but there are a couple of things I wanted to add in case you're hitting them:
We often see this when snapmirror.conf is setup incorrectly, or DNS between all of the sites and hosts isn't working properly. If the snapmirror update functions between the simulators (snapmirror update), then make sure that the DNS to the simulators works from the hosts that are running the SRA.
If you have any "mistakes" in the exports file, or are listing the exports with the -actual option, or you've got a volume in the exports list more than once, you will also end up with this error.
To help troubleshoot and narrow down "where" the problem is coming from, you can check the audit logs from the simulator to see if the IP address of the SRA is actually sending ZAPI calls to the simulator, if it's not, then you will know the problem is within the configuration of the SRA; if it is, then you know the problem is with the configuration on the controller itself.
Yes there are replciaed machines on the voluome and I have had to enable this that to add the array in to SRM manager to work, but now when scaning after the enabling, this is were I get the same problem.