showmount -e should work even with cluster but unlike 7-Mode you have to use data LIF IP address. In 7-mode you can use IP or name of node but as in cluster mode clust name or vserver name are logical entitiy which does not own any IP rather LIF owns an IP so use LIF IP address.
> showmount -e lif-IP
Greetings!
I had an identical issue with AFF running 9.5. One day everything OK, the next some users lost their Supplementary GIDs listings and consequently access to their shares. I had to reboot the node in question.
Any idea why this happens, how to fix it non-disruptively, and how to avoid it alltogether?
Sincerely,
Storagerix
Hi,
We have a requirement to provide RO access to all CIFS shares of SVM1 for a domain group, who further uses MMC to view the shares. Can you suggest how can we acheive this?
Using Computer Management, you can connect to the CIFS Server and configure permissions exactly the same way you would for a Windows CIFS Server. Add permissions to the shares directly from the Shares link.
Hi there,
I like to do these things at the command line:
security login create -user-or-group-name "domainname\ROGroup" -application http -role readonly -vserver svm_95_nas -authentication-method domain
You may want to do multiple entries for the application modifier if you want them to have access other methods as well, typically "http, ontapi, ssh".
Then add those users to the AD Group called "ROGroup" or whatever you call it in your domain.
I need some further information to help you with this. The type of Linux client, the version, the kernel version, etc.
I'd also like to know the serial number of the filer in question.
I'd also like to see packet captures attempting the access to the cifs share.
I'd also like to know the name of the cifs share.
I'd also like to know the ip address of the client attempting to access the cifs share as well as what IP address on the filer it's attempting to access.
There's a lot of variables here that could be causing problems so I apologize about all the questions.
Hello Netapp Community,
I am having a big challenge that just started a week ago. My Netapp Nearstore storage system Model R200 and version 7.2.4 stopped authenticating clients. Whenever a client would try to access a CIFS share using the IP address of the storage system, it would prompt for username and password and still reject the authenticated user, while if the user used the hostname all is well. Kindly advise on what I need to change or do to resolve this.
Much appreciated.
Kevin Martin
Use of IP address forces NTLM authentication. It is possible that your organization restricted or blocked NTLM.
Hello aborzenkov
However this has been working for more than 5 years without any issue and no policy or modification has been made on both windows and Storage systems. Unless this is a because of an update from Microsoft. Any other options I can look out for as I am new to storage and not sure how to check on the NTLM authentication configurations.
Regards,
Kevin
We used to try the DNS c-name failover method several years ago but always hit the issues you describe when testing failover - TTLs causing clients not to redirect to the DR CIFS vserver, DFS caching/TTLs compounding the issue - eventually some clients redirect and some dont....not good. You end up troubleshooting DNS/DFS, knowing that your DR shares are available via hard UNC links \\servername\share, while the bosses are saying "Great. We gave you all that money for Netapp and when you fail-over, 100s of clients cant connect!"
Also, we have hundreds of shares, so messing around with DFS targets isnt really an option.
At 10,000ft, what we did to get round it in 7-mode, (AND WE'VE ADAPTED THE METHOD FOR C-MODE) was:
1. Create an OTV VLAN between production and DR site LANs, so that IP addresses of the production and DR CIFS vserver are on the same subnet. THIS MAKES FAILOVER SOOOOO MUCH EASIER - IT TAKES HAVING TO TOUCH ANY OTHER SUPPORTING INFRASTRUCTURE (DNS, DFS, etc) OUT OF THE PICTURE WHEN PERFORMING FAILOVER STEPS.
2. Create a 'dummy' vserver at the DR site, with a placeholder CIFS/AD name and IP address.
3. Production site goes down (test or real-life). At DR site -
Break your snapmirrors!
Delete dummy vserver/ SVM's IP address and replace with production CIFS IP address. (no duplicate conflict since primary is down!)
Delete dummy CIFS server config from vserver/SVM and re-create CIFS server config for DR vserver/SVM so that name matches failed primary CIFS vserver AD name. You need to join AD domain with this name, and you can re-use the AD object of the failed primary CIFS server (you should probably 'reset' the account in AD).
4. CIFS server should now start at the DR site and you should be able to ping the name of the failed primary CIFS server on its original IP!
5. Re-create your CIFS shares manually or import them via Powershell.......
6. Good to rock and roll!
We've used this in real life and it was as good as gold.....RTO was within 30mins for all clients instead of hours with hundreds of clients working and hundreds of clients not working.
main caveat: USE OTV VLANS!!!
Hello;
We hav an AFF 200 with all svm's are connetcted via VLAN 50 and Lif a0a an 4 port LACP Etherchannel on our Cisco Switch(switchport access vlan 50).
To improve the security, we want to seperate the NFS traffic to the ESXI Hosts with a new Vlan id 10
But that means to change the Port config of the Switch to trunk(Switchport mode trunk).
I would follow this steps:
1. Create an svm_lif for NFS with the new IP in the Vlan 10
2. Edit the NFS Export Policy for the ESXI Host IP's
3. Create 2 new LACP Etherchannel on the Cisco Switch with Switchport mode trunk
4. Takeover the Node 1
5. Connect the 4 Connections to the new LACP Trunk Etherchannel
6. Takeover the Node 2
7. Connect the 4 Connections to the new LACP Trunk Etherchannel
8. Giveback
Can you please correct me when i'm wrong?
For NFS Expot, do i need a "switchport mode trunk switchport nativ vlan" setting?
Many Thanks, Thomas
Hi, I have received a request to put together a process tostop access to CIFS shares mapped to virtual desktops in the event of a malicous attack to limit the the impact of users inadvertantly spreading the corruption. My first thought is to simply stop sharing the individual CIFS share or disabling CIFS altogether thus disabling access completely.
Both would stop access to the shares but I'm wondering if there are any other options either NetApp or third party that anyone has used and would recommend?
Thanks in advance,
JennerSRB
You shouldn't need to do the takeover/givebacks. That was more a 7mode thing.
You should just be able to move the lifs around, add new lifs and reconfigure/add vlans. Just be sure to evacuate any port/ifgrp you're working on.
After your done, be sure to verify failover groups on your lifs.
Hi Jenner,
Best thing against malicious attacks would consist of at least the following:
1. proper backup (plus snapshot) policy
2. setup fpolicy to prevent known extensions, thus preventing encryption
3. in case of a known malicious attack:
a. Create a snapshot IMMEDIATELY so you know what is going on
b. either stop CIFS services
c. or set all CIFS shares to readonly (this will impact your business less and prevent encryption/deletion as well
The steps in point 3 can be easily automated using powershell SDK or linux shell scripting depending on your environment.
Make sure to make the scripting dynamic so newly created/deleted CIFS shares are automatically added.
Besides that you should look into a good security information and event monitoring service so you get early alerting on when attacks happen. Unfortunately we cannot prevent such attacks but timely detection can save you loads of work and problems.
/Xander
wrote: Hi Jenner,
Best thing against malicious attacks would consist of at least the following:
1. proper backup (plus snapshot) policy
2. setup fpolicy to prevent known extensions, thus preventing encryption
3. in case of a known malicious attack:
a. Create a snapshot IMMEDIATELY so you know what is going on
b. either stop CIFS services
c. or set all CIFS shares to readonly (this will impact your business less and prevent encryption/deletion as well
The steps in point 3 can be easily automated using powershell SDK or linux shell scripting depending on your environment.
Make sure to make the scripting dynamic so newly created/deleted CIFS shares are automatically added.
Besides that you should look into a good security information and event monitoring service so you get early alerting on when attacks happen. Unfortunately we cannot prevent such attacks but timely detection can save you loads of work and problems.
/Xander
Hi Xander,
Thanks for the reply and I concur with all the points you have made. i hadn't consdiered making the CIFS shares readonly but that is a good suggestion.
Thanks again,
Jenner.
Hi
if you want - NetApp has a full DOC about that topic - "The NetApp Solution for Ransomware"
https://www.netapp.com/us/media/tr-4572.pdf
Gidi
Thanks a lot, i will try it this week.
But on the Switch i need to connect to a new LACP Etherchannel, so i need to reconnect the cables, for that i have a Networkouttake, which i could avoid with th takeover/giveback, is that wright?
many Thanks, Thomas
can you explain what you mean by "networkouttake"?
But there's nothing you need to do when reconfiging networking ports that involves takeovers/givebacks.
Just evacuate all lifs on the VLANs and ports your working on to the partner or other nodes in the cluster.
I need to change the switchport setting from defined vlan to trunk, sorry for my bad exlanation...
Thanks, Thomas