On 12/5/2014 6:16 AM, dbgallo wrote:
>
> Still getting started with NSM4.0......
>
> When running GSR, seeing lots of errors for " Error#28 (File system path
> could not be found.)" when I can actually find the path in the browsers,
> looked in the Storage Resource List and instead of seeing
> clusterresource\volumename (which is the path in the string that is
> erroring above) I'm seeing clusternode\volumename. This is what is
> causing the issue in the previous thread. Tried to do a rebuild and got
> the same results. Users see the volumes as clusterresource\volumename,
> and that is how they are mapped in the login script,
>
> How/where do I look to correct this?
>
> thanks in advance
>
>
Make sure that the nsmproxy object has Supervisor rights on the virtual
server and its resources. We've very rarely seen cases where inheritance
of Supervisor rights from the root of the tree stops at that level on
cluster volumes.

-- NFMS Support Team

On 12/5/2014 9:44 AM, NFMS Support Team wrote:
> On 12/5/2014 6:16 AM, dbgallo wrote:
>>
>> Still getting started with NSM4.0......
>>
>> When running GSR, seeing lots of errors for " Error#28 (File system path
>> could not be found.)" when I can actually find the path in the browsers,
>> looked in the Storage Resource List and instead of seeing
>> clusterresource\volumename (which is the path in the string that is
>> erroring above) I'm seeing clusternode\volumename. This is what is
>> causing the issue in the previous thread. Tried to do a rebuild and got
>> the same results. Users see the volumes as clusterresource\volumename,
>> and that is how they are mapped in the login script,
>>
>> How/where do I look to correct this?
>>
>> thanks in advance
>>
>>
> Make sure that the nsmproxy object has Supervisor rights on the virtual
> server and its resources. We've very rarely seen cases where inheritance
> of Supervisor rights from the root of the tree stops at that level on
> cluster volumes.
>
> -- NFMS Support Team
After that, rebuild the Storage Resources cache.

-- NFMS Support Team

Did all over the above with the NCP object, Volume Object, Cluster object and cluster resource object ran rebuild and discover , rebooted server, ran rebuild and discover.

Went thru the entries between two volumes in the same cluster, one that shows up in the Storage Resource list and the one that doesn't that I modified the trustees on. Outside of the trustee rights on the volume that shows NOT having nsmproxy listed, there was no difference.

Then I remembered an issue we had when we implemented kanaka for some MAC clients. In the cluster volumes that had been migrated from Netware NCS to OES11 NCS the NCS:Volumes and NCS:Volume attributes had not been set to the cluster object. Re-read TID 7010304 https://www.novell.com/support/kb/doc.php?id=7010304 and followed those steps. Rebuilt the Storage Resource List and the clusternode\clustervolume was replaced by the clusterresource\clustervolume. Problem solved.

Might want to add that to the troubleshooting toolkit....