While not fun, there are a couple of possibilities to deal with the situation described.
Clustered Data OnTap has two differences on NFS exports that need to be considered when migrating from 7-mode. The first is as you describe - the inability to export a deep path. The second (related) is the inability to use an "actual-path" on an export definition, where the "export" is an alias to a real path. This second case is common enough when there has been storage consolidation or reorganization but the need to keep a "virtual" export name remains.
NetApp has taken the position that the ability to mount a volume to any point in a logical name space (junction paths) eliminates the need to do either of these two export styles that were available in 7-mode. Unfortunately, while junction-paths are nice, they don't cover all the real-world possibilities that the 7-mode capabilities are used for.
So - how to address the situation? Two ways are possible, depending on your case. Neither are pretty.
1. Qtrees can have their own separate export policy under Clustered OnTap. So, you can have a volume that has an export policy, and a qtree on that volume that has a separate export policy. NFS mounts at the volume level will apply that policy to the underlying qtree. NFS mounts at the qtree level will apply the qtree export-policy to just that space.
Drawbacks: If you don't have qtrees in place now, you would have to migrate by copying data into a new volume/qtree setup - snapmirror is insufficient. Also, if your deep path export is more than one level deep under the volume (as in the case below) you can't create a qtree - the old rules still apply in that qtrees are created in the logical root directory of a volume.
2. Volumes can be mounted anywhere in the hierarchy. In the case below - the solution to retain the same NFS structure is to create two volumes rather than one. The first volume is "vol_test". Call the second volume "vol_test_aaa_bbb". Still a manual copy, but "vol_test_aaa_bbb" would contain all the data that exists as /vol/vol_test/aaa/bbb from a 7-mode NFS point of view. Volume "vol_test" would contain everything else. "vol_test" might get a mount point on Clustered OnTap (junction-path) of /vol_test with an export policy that allows 192.168.1.10 access. "vol_test_aaa_bbb" gets a mount point (junction-path) of "/vol_test/aaa/bbb" and an export policy that allows 192.168.1.11 access.
NFS (and CIFS) shares are defined through the mount-point hierarchy on Clustered OnTap as opposed to paths that are specific to the volume (i.e. you don't start with /vol/... in the path - you start with "/" and work through the junction-path hierarchy). The export-policy that applies to any access depends on where you enter the hierarchy (much like as in 7-mode). You can build any structure at any number of levels (to system limits of course) with junction-paths and simulate the same structure you had in 7-mode. It just takes more effort to do the migration and more administration overhead as you are now creating two volumes from one in order to maintain the logical structure of the data.
Hope this idea helps you.
