Forgive me, I am not a NetApp person. I'm setting up a virtual simulator for my developers to do their thing in creating functionality for their software...very simple setup for them...
The problem I am having is I cannot access my CIFS shares on the CIFS Server from anywhere on my network
External virtual systems are:
VMWare ESXi 6
Windows 2012 A/D, DNS, DHCP
I've been successful with the following...
Creating Single node cluster (all that is required).
Creating Second aggregate
Creating SVM with assigned subnet/nic
Creating vols on SVM
Configuring the SVM for CIFS (added to Windows 2012 AD domain)
I cannot see the CIFS server nor it's shares...even the C$.
To me it appears the shares are not properly being shared out by Winders.
Any assistance would be appreciated...
CAMINO::> vserver cifs show Server Status Domain/Workgroup Authentication Vserver Name Admin Name Style ----------- --------------- --------- ---------------- -------------- camino-02 CDOT-HSM up SBC domain
CAMINO::> vserver cifs share show Vserver Share Path Properties Comment ACL -------------- ------------- ----------------- ---------- -------- ----------- camino-02 admin$ / browsable - - camino-02 c$ / oplocks - BUILTIN\Administrators / Full Control browsable changenotify camino-02 eng /home/eng oplocks - Everyone / Full Control browsable changenotify camino-02 finance /home/finance oplocks - Everyone / Full Control browsable changenotify camino-02 home /home oplocks - Everyone / Full Control browsable changenotify camino-02 ipc$ / browsable - - 6 entries were displayed.
Only need the one... So always using unique name for each SVM configuring CIFS for joining to AD.
I manually go in and add the DNS entry. Can ping the IP addy as well as the dns name
I don't think I'm terribly off on this. But I did find an interesting "anomaly"
My developer creates his vserver with an "NIS Switch" (vserver create -vserver camino-02 -rootvolume root_vs0 -aggregate aggr1 -ns-switch nis -rootvolume-security-style ntfs -language C.UTF-8)
Not sure NIS Switch / Domain is actually necessary in this case. I've had this all setup successfully before without them and was able to map drives to the shares. I say that because by enabling diag trace logging (diag secd trace set -node local -trace-all yes), I was finally able to get an event log after failing to map to the volumes...
Not sure it's the user mapping. Have not needed it is successful attempts before. That leaves the question of NIS within this rabbit hole.
secd.cifsAuth.noNameMap: vserver (camino-02) CIFS name to UNIX name mapping problem. Error: User authentication procedure failed [ 21] User 'SBC\stuart' authenticated using NTLMv2 security [ 21] Trying to map 'SBC\stuart' to UNIX user 'stuart' using implicit mapping **[ 23] FAILURE: 'NisDomain' configuration not available [ 23] NIS configuration not found for Vserver 4 [ 23] No servers available for NIS, vserver: 4, domain: . [ 23] NIS configuration not found for Vserver 4 [ 23] No servers available for NIS, vserver: 4, domain: . [ 23] Source: NIS unavailable. Entry for user-name:stuart not found in any of the available sources [ 23] Trying to map user to the default UNIX name 'pcuser' [ 23] NIS configuration not found for Vserver 4 [ 23] No servers available for NIS, vserver: 4, domain: . [ 23] NIS configuration not found for Vserver 4 [ 23] No servers available for NIS, vserver: 4, domain: . [ 24] Source: NIS unavailable. Entry for user-name:pcuser not found in any of the available sources
Message Name :secd.cifsAuth.noNameMap Sequence Number :4473 Description :This message occurs when a CIFS authentication succeeds, but system cannot map the Windows user to an appropriate UNIX user. Action :Examine the failure details to determine corrective action. Common failures include no appropriate Windows-to-UNIX name mapping rules, no configured default UNIX user, or the inability of the
system to communicate with NS-SWITCH authorization sources.
An incorrect NIS configuration can prevent CIFS from working. If NIS is configured on the SVM make sure the nis domain and nis server are valid, and the nis server is operational. If NIS is not in use, then either ommit nis from the ns-switch option or place it at the end of the list (file,nis). In this case the nisdomain should be blank.
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.
Thanks for the help. I believe I got it. I compared the creation of the SVM via command line with the NIS options against the SVM creation via the OnCommand GUI and noticed a difference in the way the nis was being enabled. So I will revisit the nis options during creation on another lab simulator to determine the correct syntax.
All volumes/shares are now available on the network as expected.