can't mount vobs in windows region but can access the vob storage path

Question

I am not been able to mount vobs in windows region but I have been able to access the vob storage location through windows explorer.
When I run cleartool mount -all, it generates the following error:

cleartool error: the vob storage directory \\..\... is not found.

When I try to start dynamic view, it generates:

cleartool: Error: Could not register gpath in the prefix map

Do you have any suggestion?

Answer 1

As mention in this thread:

The "prefix map" referenced here means a UNC path. This error means that for some reason, your NFS client was unable to create a valid UNC path for ClearCase to traverse. Check if your NFS client is working properly, and if the UNC path is valid (eg readable at the least)

One potential solution (which may or may not apply to your environment) is for a mixed interop environment where all the VOBs and dynamic views are located on two Linux servers and SAMBA is used for sharing the storage areas from Linux to Windows CC clients.

Start->Settings->Control Panel->Clearcase->
  Options Tab->
  Uncheck "Enable automatic mounting of NFS storage directories"->
  Apply->Ok

---

This thread also mentions:

I've seen similar before. The cause of our problem was incorrect access permissions to our UNC path equivalent of \\piglet\viewdata\pete_te_31.1.vws.
From explorer, try to map a drive to piglet's share, viewdata.

An alternative to that is a result of a different but not wholly dissimilar problem we had concerning NT (4.0 sp 4) client resident views accessing UNIX (Solaris 2.6) resident VOBs. We use DiskAccess to achieve this. The problem read as follows:

Occasionaly, on clients with existing mappings to VOB storage they would be presented with the error message:

mvfs: ERROR: view=fi65115_fesco vob=\fesco_orion - ClearCase vob

error see view_log on host blah blah.

Or alternatively for clients without existing mappings to VOB storage making new mappings, would simply see an empty drive i.e. L:\ (UNC equiv equals \\fiscdub002\vobstorage).

We found that we had to manually 'reshare' vobstorage with the following (as root) from our Solaris 2.6 VOB server:

share -F nfs -o rw /dub2box1 (where /dub2box1 is vobstorage).

So to recap, check the permissions to the share and verify that the share has 'contents' (for want of a better way of putting it).