StorNext Client to Access Xsan Volumn

gwu's picture


I am running xsan 2.2(248) on Mac OS X Server 10.6.7 (IP:
storNext file system client 3.5.2 Build 15359 (built for windows XP/2003/vista/2008) AMD64 bits version on windows 7 (IP:
so compatibility is perfectly fine.

StorNext Client License installed. .auth_secret installed.

StorNext "Client Configuration" utility shows XSAN file system mounted, status Available.

C:\Programe Files\storNext\bin\cvadmin

Select FSM "DS1"

Created: xxxxxxx
Active Connections: 2
all look fine.

snadmin > who
shows that
CLI connected license is Permanent.

snaadmin > paths
shows all the LUNS and being available.

however, i just can not access the mounted XSAN volume on the window machine. totally access denied.

and seen from the xsan admin on the Mac OS sever, mounted computers do not include the windows storNext machine. and if I try to manually add a remote computer for the windows StorNext machine, at the authentication stage, it is always unreachable or offline.

no firewall on Mac OS X or windows (and as we seen above, windows actually perfectly see and mounts the XSAN, just can not access due to permission issues)....

any clue on what went wrong?

our XSAN was configured by 3rd party before, it seems to be using local OpenDirectory to manage users. anything we need to adjust here?

and is any DNS setting we need to adjust too? basically, the hostname of the windows machine is "Admin-PC" and we can not resolve that name to IP on Mac OS server (Does this matter?)...and the MacOS Xsan Server machine has a hostname of "" (we created a domain name on the local DNS server, not public Domain name at all) and this can not be resolved to IP on the windows StorNext Machine too...anyway, we did not configure anything specially for DNS and we dont need internet access, so we did not bother.
anything wrong with our DNS setup(even all IP based connectivity are working well)?

or anything wrong at the metadata access?

we have been suffering this issue for months and had to use Samba over ethernet for the time being but it is too slow.

Thanks a lot and let me know if you need more info to trouble shot.

abstractrude's picture

sounds like everything is working from a stornext standpoint you latency-test to make sure it sees the client from the cvadmin menu. you will only see OS X clients and controllers in the computers section of xsan admin.

your problem probably lies in permissions on the windows machine. you will need to make sure the windows machine has write access. look at properties and security settings on windows. pretty sure you need an NT security descriptor in there. if i remember correctly it can sit in the extended attributes section alongside os x ACL.

long story short. permissions probably.

-Trevor Carlson

gwu's picture

Hi abstractrude

Thanks for your hint.

more info:

Below images shows the StorNext Client mounts the xsan volume and status is available.


Permission on Windows machine shows that administrators has no access to this mounted xsan volume (all permission not checked) and we can not change the permission as those permissions are all greyed out... are you talking about we need to add/change permission here? and how?


Below image of xsan mount on windows machine, LUNs/Disks/Who/Latency-test using cvadmin on windows.


However, this is the ACL we currently have on the Mac OS X server, ACL control only have administrators (i think it is the mac OS administrators grp, not the windows grp), Do we need to add any ACL here? and what to add?


also , according to this page:


If you have a mix of Windows clients and Xsan clients, they must all be bound to the same directory domain, whether provided by Open Directory configured as a primary domain controller (PDC) or by Windows Active Directory.
[end quote]

We are not sure about this....for our windows machine, we just simple connected the Fiber nework and metadata network and installed storNext, we did not do anything specially about the "same directory domain" thing. are we missing anything here?

gwu's picture

Thanks abstractrude for the hint.
Yes, it is an ACL issue. fixed.

simonjoh4nsson's picture

gwu wrote:

Thanks abstractrude for the hint.
Yes, it is an ACL issue. fixed.


I have exactly the same issue, could you specify in more detail HOW you fixed it?