Description of problem:
If the path to be mounted contains a symlink pointing to a different file-system, the nfsv3 mount fails and returns error. That's because in our current implementation, we do not check for the possibility of having cross-junction paths in the v3 mount path.

Consider two volume (say /vola , /volb) exported via NFS-Ganesha. If incase the mount path is either of
a) $IP:/vola/../volb  or
b) $IP:/vola/path_to_a_symlink_file_s1/   where 's1' is a symlink file linked to /volb 
then the mount fails and throws an error. 

But the same is not the case with NFSv4 mount. The reason being, as part of the NFSv4 mount, the client issues lookup on each dir of the mount path, and hence while traversing the server would be able to detect it if it comes across any junction path to different file-system and so evaluates export_permissions accordingly. 

Also v3 kernel-NFS mounts work the same way as NFSv4 mounts..i.e, if encountered a different file-system in a mount path, the server evaluates the export permissions of that file-system as well before granting access to the client instead of aborting the command.


How reproducible:
All-time

Steps to Reproduce:
As mentioned in the description above, issue NFSv3 mount command using any of the symlink path linked to a different volume path. 


Actual results:
v3 Mount command fails and throws an error.

Expected results:
Ideally NFSv3 mount should also be able to detect the junction paths if present in the mount path and apply export-rules accordingly before granting access to the client.