Hello,
We we getting ready to consolidate several older filers onto a single FAS3040. Each of these older filers had several CIFS shares exposed. My users are used to going to the Run box in windows and typing \filerA to get filersA's shares and \filerB to get filer B's shares and so on.
But now there is just \Newfiler. This produces a list of all the CIFS shares that used to be on several different filers.
Is there a way to group several cifs shares together and present them in a folder, or another share ?
I would like to be able to go to \NewFiler, and get a window that has a few folders, each of which holds several shares.
I don't think this can be done, but I thought I would ask here anyways.
Thanks,
Paul
You should use the CIFS Aliases feature, your new filer answers for both of the other names as well....works as longas you don't have conflicting share names on the two older filers.
-Glenn @ Voyant
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner- toasters@mathworks.com] On Behalf Of Paul Letta Sent: Thursday, July 26, 2007 4:17 PM To: toasters@mathworks.com Subject: CIFS shares presentation to users
Hello,
We we getting ready to consolidate several older filers onto a single FAS3040. Each of these older filers had several CIFS shares exposed. My users are used to going to the Run box in windows and typing \filerA to get filersA's shares and \filerB to get filer B's shares and so
on.
But now there is just \Newfiler. This produces a list of all the
CIFS
shares that used to be on several different filers.
Is there a way to group several cifs shares together and present them in a folder, or another share ?
I would like to be able to go to \NewFiler, and get a window that has a few folders, each of which holds several shares.
I don't think this can be done, but I thought I would ask here
anyways.
Thanks,
Paul
This works well. We used it for this exact situation. We consolidated several old file server onto our NetApps and just aliased the filers in DNS and using the CIFS Alias feature (takes care of NetBIOS registration).
The one caveat to this is folder & share names. If you have \serverA\foo and \serverB\foo you'll need to resolve this collision before moving your data and setting up the shares. If there are no share name collisions, you're good to go.
DFS (from Microsoft) could also solve some of this but that's definitely a topic for a separate discussion.
Jeff Mery - MCSE, MCP National Instruments
------------------------------------------------------------------------- "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade -------------------------------------------------------------------------
"Glenn Dekhayser" gdekhayser@voyantinc.com Sent by: owner-toasters@mathworks.com 07/26/2007 04:26 PM
To letta@jlab.org, toasters@mathworks.com cc
Subject RE: CIFS shares presentation to users
You should use the CIFS Aliases feature, your new filer answers for both of the other names as well....works as longas you don't have conflicting share names on the two older filers.
-Glenn @ Voyant
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner- toasters@mathworks.com] On Behalf Of Paul Letta Sent: Thursday, July 26, 2007 4:17 PM To: toasters@mathworks.com Subject: CIFS shares presentation to users
Hello,
We we getting ready to consolidate several older filers onto a single FAS3040. Each of these older filers had several CIFS shares exposed. My users are used to going to the Run box in windows and typing \filerA to get filersA's shares and \filerB to get filer B's shares and so
on.
But now there is just \Newfiler. This produces a list of all the
CIFS
shares that used to be on several different filers.
Is there a way to group several cifs shares together and present them in a folder, or another share ?
I would like to be able to go to \NewFiler, and get a window that has a few folders, each of which holds several shares.
I don't think this can be done, but I thought I would ask here
anyways.
Thanks,
Paul
If you wan't to keep your filerA, filerB, etc names around for your Windows users you can use "options cifs.netbios_alias filerA, filerB" on NewFiler to make your users think they are accessing the old ones.
If your users go to \NewFiler they will see every CIFS share that has been created on that box (assuming you haven't enabled ABE and/or they have the rights). They can then access any that they have permissions to. If you want only a few "top level" shares simply create a few volumes and share them. On those volumes create QTrees/folders that your users will see when they open the shares.
Or you could create a volume with a few QTrees, create your CIFS shares on the QTrees and create folders under those for your users to see. Don't share the volume for them or create a share on the volume and append $ to the sharename - this will prevent it from being visible in the Windows browser but will be able to be accessed by those that know it exists and have permissions to do so.
----- Original Message ----- From: "Paul Letta" letta@jlab.org To: toasters@mathworks.com Sent: Thursday, July 26, 2007 4:17 PM Subject: CIFS shares presentation to users
Hello,
We we getting ready to consolidate several older filers onto a single FAS3040. Each of these older filers had several CIFS shares exposed. My users are used to going to the Run box in windows and typing \filerA to get filersA's shares and \filerB to get filer B's shares and so on.
But now there is just \Newfiler. This produces a list of all the CIFS shares that used to be on several different filers.
Is there a way to group several cifs shares together and present them in a folder, or another share ?
I would like to be able to go to \NewFiler, and get a window that has a few folders, each of which holds several shares.
I don't think this can be done, but I thought I would ask here anyways.
Thanks,
Paul
Is there still any need to use cifs aliases if all your clients are Win2K or later? I stopped using netbios aliases a while ago, just using dns aliases instead, and I haven't heard of any access problems since things like Win95 stopped being an issue for me.
Good afternoon everyone,
Has anyone had any delay problems using LDAP with NetApp? We're trying to implement it for user mapping purposes. It seems to be working in general; however, I am having a strange problem. Whenever I first do a query to test the connection (getXXbyYY getpwbyname_r <username>), it comes back immediately with the response. When I try it again another time or two, it still works fine. But after the 3rd or 4th attempt, there is about a 35 second delay before the response appears, and this delay happens for every query thereafter. The same delay occurs when trying wcc -u (or -s) <username>. Even trying to map a drive encounters the delay (which is the main reason we can't use LDAP until this is resolved -- users won't sit for 35 seconds waiting for every drive to map).
I have worked with the team that manages our LDAP environment, and the logs on their side show our netapp server doing the query and exiting within 2 seconds. (So what is it waiting on??) I've enabled cifs.trace_login, but it's showing no errors once the information finally appears.
We're running ontap 7.0.6 (which means netapp is using SASL -- no SSL feature).
nswitch.conf on the netapp looks like:
hosts: files dns nis passwd: files ldap netgroup: files nis group: files ldap shadow: files ldap
As far as ldap options, I have ldap.servers set to the server, and ldap.ADdomain is left blank.
Any time I disable and re-enable LDAP on the NetApp server, the delay goes away until I run a couple queries...then it always starts up again.
I'd greatly appreciate any ideas
-Brian Beaird
Actually yes =(.
While the party line from MS is that NetBIOS (aka WINS) isn't needed after Win2K, there are still some services that rely on it unless you specifically tweak them. MSCS comes to mind for sure in Win2K (that may be resolved in 2003 though - anyone confirm?). You also have to be sure that your DNS suffix search orders are correct and enforced on all your clients *before* you kill WINS. It's not so much an issue with servers as they're typically easy to control - it's the end-user machines you have to worry about.
In our shop, most people are used to going to \server_name with no fqdn. This will automatically try NetBIOS to resolve the name first before DNS. If the suffix search order isn't right, resolution fails. Group Policy is your friend here! It doesn't help for systems not on your domain though. We have several thousand engineers all with dev systems not on our domain due to the number of rebuilds they perform. Having WINS on-line makes this situation much more tolerable for our end-users and our Help Desk.
Jeff Mery - MCSE, MCP National Instruments
------------------------------------------------------------------------- "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade -------------------------------------------------------------------------
"Sphar, Mike" Mike_Sphar@bmc.com Sent by: owner-toasters@mathworks.com 07/26/2007 06:18 PM
To toasters@mathworks.com cc
Subject RE: CIFS shares presentation to users
Is there still any need to use cifs aliases if all your clients are Win2K or later? I stopped using netbios aliases a while ago, just using dns aliases instead, and I haven't heard of any access problems since things like Win95 stopped being an issue for me.
-
Bill Holland -
Brian.Beaird＠cat.com -
Glenn Dekhayser -
Jeff Mery -
Paul Letta -
Sphar, Mike