toasters

toasters@lists.teaparty.net

13531 discussions

5.2.1D5: praise and a caveat
by Brian Rice 16 Mar '99

16 Mar '99

Last Friday night I put 5.2.1D5 (the successor to 5.2.1P1) on one of the F630's. It didn't panic, and I've got my quotas back. Ahhhh, yeah. Just one leetle caveat, one which caused me to believe I had a hung filer and to place a down-filer call to NetApp technical support. It seems that 5.2.1D5 sets the floppy-boot? environment variable for you by default. So when you boot, you see something like... NetApp Release 5.2.1D5: Mon Mar 8 23:54:01 PST 1999 Copyright (c) 1992-1998 Network Appliance, Inc. Starting boot on Sat Mar 13 07:50:19 GMT 1999 Scanning for disk drives: floppy boot? .......................... Spinning up disk drives: 8a.12 8b.12 8a.13 8b.13 8a.14 8b.14 Configuring disk drives: 8b.14 8a.14 8a.9 8a.12 8b.11 8b.12 8b.9 8b.8 8b.4 8b.5 8b.1 8a.3 8a.10 8a.2 8a.11 8a.5 8b.0 8b.10 8b.13 8b.2 8b.3 8a.13 8a.8 8a.1 8a.0 8a.4 and then, apparently, the filer hangs, with the LCD saying "Configuring disk 8a.4" (or whichever one was last). Turns out that that "floppy boot?" way up there at the top was a prompt. It's waiting for you to type "yes" or "no" on the console. A "no" causes the boot to finish normally. Then a "setenv floppy-boot? false" and a reboot gives you a happy filer. Thanks to the NetApp tech support guy for reacting so graciously to being beeped in the middle of his Friday night. Brian

3 3

Re: NetApp/Auspex killer?
by Darrell Fuhriman 16 Mar '99

16 Mar '99

discussing hardware completely ignores the core of what makes the Netapp so good -- the file system. WAFL simply beats all the others -- even ext2 or veritas. Darrell

1 0

Re: 5.2.1D5: praise and a caveat
by Aimee Schmidt 15 Mar '99

15 Mar '99

> That's strange. My F760 doesn't have a "floppy-boot?" parameter. What it > does have is a "boot" (or is it "system-boot"?) parameter set to > "floppy scsi-disk". That way my box boots from floppy, if installed, otherwise > from disk. Is this different in 5.2.1D5? The boot order should be controlled > by the firmware (2.1_a2) not ONTAP. (after all ONTAP isn't running yet) > > I cannot check my 630's (firmware 1.12_a1) but I suspect they are the same. This variable is not set by default. One must execute a setenv floppy-boot? true at the firmware level (ok prompt). Conversly one can remove the prompt with the following syntax at firmware: unsetenv floppy-boot? Aimee _____________________________________________________ Aimee Schmidt aimee(a)netapp.com Software Test Engineer Voice: 408.367.3238 Network Appliance Fax: 408.367.3451 / |\ / | \ "We cannot direct the wind / | \ but we can adjust our sails" ---------- \________/ |_|

1 0

Re: 5.2.1D5: praise and a caveat
by grdodson＠lexmark.com 15 Mar '99

15 Mar '99

That's strange. My F760 doesn't have a "floppy-boot?" parameter. What it does have is a "boot" (or is it "system-boot"?) parameter set to "floppy scsi-disk". That way my box boots from floppy, if installed, otherwise from disk. Is this different in 5.2.1D5? The boot order should be controlled by the firmware (2.1_a2) not ONTAP. (after all ONTAP isn't running yet) I cannot check my 630's (firmware 1.12_a1) but I suspect they are the same. Thanks. Graydon Dodson grdodson(a)lexmark.com Lexmark International Inc.

1 0

RE: filer-mrtg
by Thompson, Tim 15 Mar '99

15 Mar '99

> > > In a fit of needing a diversion i installed > > > filer-mrtg yesterday and boy is it cool! > > Glad you found it. > > Ok, I looked on ftp.netapp.com, But I can't find it. > > Where can you get filer_mrtg? On the NOW site (now.netapp.com) in the Tools&Utilities section, in the Toolshed area. (You could also use the "Search" capability on the NOW site.) >From the README: This package uses the MRTG (Multi Router Traffic Grapher) to provide web-based monitoring for Filers. It provide a current and historical view (the last day, week, month, and year) of statistics for network traffic (per interface), CPU load, disk usage, and NFS and CIFS operations. There is also a similar netcache-mrtg package in the Toolshed. ...Tim Thompson...Network Appliance, Inc...tjt(a)netapp.com...

1 0

Filers and Lotus Notes...
by Paul Taylor 15 Mar '99

15 Mar '99

Hi. I would like to know if anyone has had any experience with NetApp filers and Lotus Notes. Here is our situation: We have an F630 that has 2 LN server attached to it (among other things), running across Fast Etherchannel. One of the LN servers is on WinNT and the other is on AIX. The AIX box is a RS/6000 H50 with a single CPU, and 512MB RAM. The NT box is a single CPU netfinity with 512MB RAM, running at 400mhz. The Filer has 512MB onboard, running DoT 5.1D12. LN is v. 4.6.2. We have 2 networks on each server, a public network that goes to the internet, and a private network (a 10. ) that goes to the filer. The problem we had at first was with LN itself not liking UNC names. For this problem I installed PCNFSD, and ran it that way for a while. Now we are experiencing corruption at random times. I figure it is probably the connectionless nature of NFS. Bah. Anyone have any better ideas? BTW: client doesn't want to do directory links, it has to run as a service, and it has to run as system. Next problem: We installed Domino on an RS6K adn it ran horribly. I moved it over to local disk, and it ran great. Hmmmmm.... Here is the mount info for the rs6k from /etc/filesystems (commented out for now since we went to local disk: * /lnmobem01: * dev = "/vol/vol0/lnmobem01" * vfs = nfs * nodename = efiler01 * mount = true * options =bg,hard,intr,rsize=4096,wsize=4096,vers=2,proto=udp account = true Anyone have any ideas as to why this would act slow when opening a DB? it takes about 1.5 min to open log.nsf, when it should take about .5 sec. Thanks, Paul

1 0

RE: filer-mrtg
by Thompson, Tim 15 Mar '99

15 Mar '99

> In a fit of needing a diversion i installed > filer-mrtg yesterday and boy is it cool! Glad you found it. >I'm having a hard time >correlating the "Network Kbytes sent >and recieved" with the "Network Interface >Sent And Received" The first one is uses the Filer's MIB entry for "miscNetRcvdKB", and the second one uses the MIB entry for the individual interface. If only one interface is used, they should match - I just checked a filer here that has a single interface, and the two graphs match well. I'll ask for more details in separate email. ...Tim Thompson...Network Appliance, Inc...tjt(a)netapp.com...

2 1

Etherchannel/trunking
by Paul English 15 Mar '99

15 Mar '99

We currently have a quad etherchannel/trunking set up working with a Cisco switch, and from Todd's post, you all know that it worked very well. Does anyone have any experience using etherchannel/trunking with any other vendors/products? Any info would be useful.. Paul -- Paul English (Tallpaul) (508) 647-7715 tallpaul(a)mathworks.com (508) 647-7015 FAX Walkie Channel 2

4 3

NIS+
by Jason Middlebrooks 15 Mar '99

15 Mar '99

I know that the netapps support NIS but what about NIS+ ????? Thanks for all the answers. Jason

3 2

filer-mrtg
by Graham C. Knight 12 Mar '99

12 Mar '99

In a fit of needing a diversion i installed filer-mrtg yesterday and boy is it cool! I do have a question for those in the know though - i'm having a hard time correlating the "Network Kbytes sent and recieved" with the "Network Interface Sent And Received" I would figure that on a system with 1 interface that these graphs should be pretty much identical - but on some systems the path of the graph is very similar but the numbers are really different - sometimes as much as 2-1 in favor of the "Network Kbytes Sent and Recieved" category. Is this a bug - or am i missing something here.... Thanks for any info you all can provide. GRaham

2 1

RE: FW: Shelves, disks, et al
by Chen, Ray 12 Mar '99

12 Mar '99

Probably because we qualified both. Dual-sourcing critical components like disk drives is standard procedure when multiple sources are available. (I can't say for sure because the qual for those happened before I got here.) Doing so has saved the posterior anatomy of more than one system vendor when it turns out that the product delivered by one source suddenly develops problems due to manufacturing process changes that occurred after qualification and/or problems that take a long time to appear (anyone remember the IBM stiction problems :-), or availability simply becomes a problem. I would imagine that most vendors don't want to qualify more than 2 both due to the cost of each qual and also because of the fact that qualifying N drives turns into an N^2 problem. If you qualify 3 drives, you have to ensure that all combinations work (e.g. a SCSI bus with drive A, B, and C works well, ditto for just drive A, B, and drive A, C, etc.). You wouldn't think that this should be an issue but it has been in the past. I think you can get away with skimping on some testing for situations where the N Gbytes and M Gbyte drives from the same manufacturer are the same family running the same firmware. But even then, I suspect you have to check for vibration issues in your supported enclosures. Ray > -----Original Message----- > From: Jonah Yokubaitis [mailto:barron@staff.texas.net] > Sent: Thursday, March 11, 1999 7:18 PM > To: Chen, Ray > Cc: 'Jim Davis'; toasters(a)mathworks.com > Subject: RE: FW: Shelves, disks, et al > > > > On Thu, 11 Mar 1999, Chen, Ray wrote: > > |The truly sad thing is that you are correct in that > |most people won't buy Michael's argument but that > |Michael is correct when he tries to communicate > |how much work goes into disk drive qualification > |and how painful the problems can be if you try > |and put in joe-random-disk drive, even the same > |model from the same vendor, and get unlucky. > | > |Heck, *I* didn't buy the argument until I spent > |a few years at another company where I exposed to > |some of what happens in drive qualification and > |saw what could go wrong in the lab and in the field. > | > |To be safe, you really need the same vendor, same > |drive, and exact same firmware and that's typically > |very hard to get unless you buy from the system vendor > |instead of the drive vendor. Even then, that's not > |a guarantee that you won't get bit, your odds are > |just better. > > Ray, > > If that's the case, then why does one of our F630s (9gig SCSI drives > in it) having 2 *different* model numbers of drives in it? All drives > came directly from Netapp. > > Jonah > > Jonah Barron Yokubaitis > http://www.texas.net <--- The ISP > http://www.giganews.com <--- News Outsourcing >

1 0

Re: CIFS share access?
by Allan Burrington 12 Mar '99

12 Mar '99

Assuming the filer can handle standard PC functionality - you can use subst to map any path to a drive letter. Target has share: C$ Within the C$ share is a directory named 'foo'. Do: subst z: \\target\c$\foo You now have z: rooted at the foo directory. -A ----- Original Message ----- From: Keith Brown <keith(a)netapp.com> To: Alexander Strauss <strauss(a)ti.com>; <toasters(a)mathworks.com> Sent: Thursday, March 11, 1999 10:27 AM Subject: Re: CIFS share access? >>I shared the directory where most of our Unix-Homes are located under >>the CIFS sharename UNIX_HOMES. There's no problem to connect >>\\filer\unix_homes, but I cannot connect directly to a sub-directory, >>i.e. \\filer\unix_homes\alex. > >As has already been stated, the cifs.home_dir option of Data ONTAP might >provide you with the functionality that you are looking for. > >However... I suspect that you *might* be under the impression that CIFS shares >are supposed to work like NFS exports in the above respect. Alas they don't. > >As you probably know, if you export "/home/keith" via NFS, it makes it possible >to directly mount any subdirectory of "/home/keith" from an NFS client (e.g. >"/home/keith/docs/cifs" or somesuch). Shares aren't like that. If you share >"/home/keith" as "KEITHDIR", all that you can connect to from a CIFS client is >"\\FILERNAME\KEITHDIR". You can't do something like a: > > net use q: \\FILERNAME\KEITHDIR\docs\cifs > >Keith >

2 1

Re: CIFS share access?
by Mark Muhlestein 11 Mar '99

11 Mar '99

You are correct, Alan; this works fine. Thanks for the good pointer. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Allan Burrington <allan(a)mirapoint.com> To: Keith Brown <keith(a)netapp.com>; Alexander Strauss <strauss(a)ti.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Thursday, March 11, 1999 11:48 AM Subject: Re: CIFS share access? >Assuming the filer can handle standard PC functionality - you can use subst >to map any path to a drive letter. > > Target has share: C$ > Within the C$ share is a directory named 'foo'. > >Do: > subst z: \\target\c$\foo > >You now have z: rooted at the foo directory. > >-A > >----- Original Message ----- >From: Keith Brown <keith(a)netapp.com> >To: Alexander Strauss <strauss(a)ti.com>; <toasters(a)mathworks.com> >Sent: Thursday, March 11, 1999 10:27 AM >Subject: Re: CIFS share access? > > >>>I shared the directory where most of our Unix-Homes are located under >>>the CIFS sharename UNIX_HOMES. There's no problem to connect >>>\\filer\unix_homes, but I cannot connect directly to a sub-directory, >>>i.e. \\filer\unix_homes\alex. >> >>As has already been stated, the cifs.home_dir option of Data ONTAP might >>provide you with the functionality that you are looking for. >> >>However... I suspect that you *might* be under the impression that CIFS >shares >>are supposed to work like NFS exports in the above respect. Alas they >don't. >> >>As you probably know, if you export "/home/keith" via NFS, it makes it >possible >>to directly mount any subdirectory of "/home/keith" from an NFS client >(e.g. >>"/home/keith/docs/cifs" or somesuch). Shares aren't like that. If you share >>"/home/keith" as "KEITHDIR", all that you can connect to from a CIFS client >is >>"\\FILERNAME\KEITHDIR". You can't do something like a: >> >> net use q: \\FILERNAME\KEITHDIR\docs\cifs >> >>Keith >> > >

1 0

Re: NFS fundamentally broken ??? (HA implications)
by mds＠gbnet.net 11 Mar '99

11 Mar '99

On Wed 10 Mar, 1999, Philip Thomas <thomas(a)act.sps.mot.com> wrote: > Hi, > An experienced sys admin and a colleague of mine argue that > NFS is "fundamentally broken", in the sense that because of > it's stateless architecture, a NFS client can "hang" during > shutdown if it's NFS server(s) does not respond. > This is aggravated when an "ack" is lost between server/client. > He claims to have gone through NFS code while he was at a prestigious university. > Granted I am not an expert, all the years I have worked with NFS, > I never had a problem shutting down a system because it's NFS > mount was not "responding". > But I am hoping for folks with "theoretical" background to shed some > more light into the above argument. > Both from experience, and from what I know of the workings of NFS, it *is* possible for a client to hang for valid reasons, even when shutting down, on mounts from unresponsive NFS servers. You can work around this by using dangerous options like soft mounts, or by killing processes that are using the NFS mounted areas and forcing the client to umount problem mounts. Excitingly, NetApp's use clever status-monitoring such that they can maintain NFS locks (even though they're just advisory) when the server reboots, and they, as servers, can suffer from clients that have died away with open locks. NetApp's spend some time every few minutes looking for such clients, and slowing down a bit while they do so. They also syslog a lot about that sort of thing. So there's a bit of a two-way street here, even though NFS is putatively stateless. We recently hit a bug related to that and a very helpful NetApp engineer (who I won't name to save him any embarrassment) is looking at how to smooth out that sort of wrinkle in the future - in fact at least part of that is going into a patch release in the near future. Check out the differences between intr and non-intr, and soft and hard mount options in the man-pages, and Hal Stern's book - I think that might make things clearer. > This brings to the second question. > The same person emphasize the above issue as an added reason for not > having NFS mount points on his HP High Availability (ServiceGuard). > Is there any site out there, in this wide world, using HP's ServiceGuard > (or any other HA) on a system that is an NFS client and would like to > comment on their experience in private or in this forum. Ah. There he has a point in principle, but in practicality I'd expect there to be no particular issue. We run a couple of Sun HA1.3 clusters here, and there's a Sun Cluster 2.x going in that I've had some sight of. They all use NFS mounts to import filesystems from servers, both Unix and NetApp. The design of HA clusters basically hinges on timeouts (as NFS does itself, thinking about it). If a node in an HA cluster must go down, it *will*, even if it's hanging on NFS mounts from elsewhere - usually because one timeout or other will trigger it's suicide, or for a sibling to commit fratricide (sororicide?). Obviously suicide or fratricide leaves a machine open to problems where neat and tidy shutdown without hanging on NFS mounts will be far superior. The fact that one node is having problems with an NFS mount probably means the other node(s) will too, and that will impact the overall HA cluster, which is bad(tm). So the secret is to make sure any mounts in an HA cluster are (a) required absolutely for the function the cluster provides and (b) are at least as reliable as the cluster is intended to be. I'm happy to use our NetApp's fs's on our HA clusters. I happen to think the group implementing the Cluster 2.x environment are storing up problems for themselves by using Unix NFS servers. Your mileage will vary. Hope that's helpful. > > Philip Thomas > Motorola - PEL, M/S M350 > 2200 W. Broadway M350 > Mesa, AZ 85202 > rxjs80(a)email.sps.mot.com > (602) 655-3678 > (602) 655-2285 (fax) >-- End of excerpt from Philip Thomas

2 1

Re: CIFS share access?
by Keith Brown 11 Mar '99

11 Mar '99

>I shared the directory where most of our Unix-Homes are located under >the CIFS sharename UNIX_HOMES. There's no problem to connect >\\filer\unix_homes, but I cannot connect directly to a sub-directory, >i.e. \\filer\unix_homes\alex. As has already been stated, the cifs.home_dir option of Data ONTAP might provide you with the functionality that you are looking for. However... I suspect that you *might* be under the impression that CIFS shares are supposed to work like NFS exports in the above respect. Alas they don't. As you probably know, if you export "/home/keith" via NFS, it makes it possible to directly mount any subdirectory of "/home/keith" from an NFS client (e.g. "/home/keith/docs/cifs" or somesuch). Shares aren't like that. If you share "/home/keith" as "KEITHDIR", all that you can connect to from a CIFS client is "\\FILERNAME\KEITHDIR". You can't do something like a: net use q: \\FILERNAME\KEITHDIR\docs\cifs Keith

1 0

FW: Shelves, disks, et al
by Alvarado, Michael 11 Mar '99

11 Mar '99

-----Original Message----- From: Stephen C. Woods [mailto:scw@sprynet.com] Sent: Wednesday, March 10, 1999 12:45 PM To: toasters(a)mathworks.com Subject: Shelves, disks, et al I've got a couple of questions for the list. (1) Can 9 GB drives be used in the same type shelves as 4 GB drives? I'm talking about narrow drives here. (2) Can they be mixed (4 and 9 GB drives) in a shelf? How about on the same controller? (3) Is there any source for drives other than Netapps? (4) If one obtains drives from another source can they be put under support (yeah I know, fat chance)? Would they void current hardware support? Would they void software support? (5) If I had some extra narrow shelves is there a market? We're thinking about decommissioning one of our older filers. Reply-to set to the list, as I'll bet dollars to doughnuts that other folks are interested. Thanks in advance Steve Woods ******************************************************************** Hi Steve and to the other members of the toasters(a)mathworks.com list I am happy to answer the questions you posed about Network Appliance storage Regarding the question about using non-Network Appliance disk drives in our filers. Our policy is that only Network Appliance-supplied disk drives can be used in our filers else the warranty is voided on the filers. There are very good reasons behind this policy. 1. Extensive screening and thorough integration is the difference. Network Appliance-supplied drives are burned in, carefully integrated, and screened to minimize reliability problems and maximize uptime. 2. Special driver software. Network Appliance drives have special driver software that has been written to optimize the performance of drives and filers. Every disk drive has unique characteristics. We carefully evaluate those characteristics and we specify specific changes to ensure the best possible performance. 3. Must meet exacting specifications. Drives are often seen as indistinguishable and interchangeable. This is not the case. 9 GB drives can differ by power consumption, vibration characteristics, firmware levels, revision levels, cooling requirements, actual performance, and quality. Network Appliance tests to ensure those specific characteristics working well together. So, just buying a 9 GB drive is not the answer. Buying to our engineering and purchasing specifications is what is needed. 4. Total Solutions. Network Appliance provides a total product solution. These drives are part of the total Network Appliance solution. Our total solution is not designed to work with other components, even if the raw component manufacturer is the same. 5. Support, Support, Support. Support and service are an integral part of our products. The advance replacement feature and technical support on our products is part of what sets drives purchased from Network Appliance apart from drives purchased from others. We stand behind our drives in a way other outlets won't. 6. Extensive quality control. NetApp has an extensive quality control system in place. We have to be sure of the whole process by which components (such as disk drive) are manufactured, tested, and delivered. Purchasing from another source prevents Network Appliance from ensuring the customer of the quality they depend on. Plus, the unique changes our vendors perform for us will not be found in drives purchased from other sources. 7. We fail what commodity outlets buy. Finally, drives that customers can buy from commodity outlets have failed the exacting quality, performance, and reliability standards of Network Appliance. Network Appliance has specifically rejected the drives that show up at these venues. In addition, drives at commodity outlets are subject to damaging handling and failure-inducing shock and vibration. Customers who buy from commodity outlets suffer greater data loss, shorter drive life, and higher incidences of failure and downtime. Regarding the question about using 9 GB drives in the same shelves as 4 GB drives, there are several guidelines that need to be heeded. First, the disk shelves that supported 4 Gb drives did not support properly the 9 Gb drives and network Appliance was forced to go to a new shelf design. Therefore, our engineering analysis determined that putting 9 GB drives in the 4 GB shelves would result in insufficient power and cooling to ensure the reliability our users have come to expect from Network Appliance. Second, there are guidelines for using 4 GB drives in new filer models. These guidelines take into account the operating system limitations of each filer. Be sure to review the technical product bulletins to ensure that the operating system limits on your filer are accounted for in terms of total storage capacity as well as the maximum number of slots available for the dual-channel SCSI adapters. Let me summarize these guidelines for you: Filer Storage Options F220 14 x 4 GB Fast Narrow SCSI drives F330 28 x 4 GB Fast Narrow SCSI drive OR 14 x 4 GB Fast Narrow SCSI and 7 x 9 GB drives F540 52 x 4 GB Fast Wide SCSI drives OR 26 x 4 GB Fast Wide SCSI and 13 x 9 GB Fast Wide SCSI drives Note: 4 GB count could include up to 24 Fast Narrow SCSI drives F210 14 x 4 GB Fast Wide SCSI drives OR 7 x 9 GB Fast Wide SCSI drives F230 14 x 4 GB Fast Wide SCSI drives OR 14 x 9 GB Fast Wide SCSI drives OR 7 x 4 GB and 7 x 9 GB drives F520 28 x 4 GB Fast Wide SCSI drives OR 28 x 9 GB Fast Wide SCSI drives OR 56 x 9 GB FC-AL drives OR 14 x 4 Fast Wide SCSI GB and 14 x 9 Fast Wide SCSI GB OR 21 x 4 GB Fast Wide SCSI and 7 x 9 GB Fast Wide SCSI OR 7 x 4 GB Fast Wide SCSI and 21 x 9 GB Fast Wide SCSI F630 52 x 4 GB Fast Wide SCSI drives OR 52 x 9 GB Fast Wide SCSI drives OR Up to 168 x 9 GB FC-AL drives OR Up to 84 x 18 GB FC-AL drives

2 1

Re: cifs reconfiguration (workgroup -> domain)
by Keith Brown 11 Mar '99

11 Mar '99

>Caution: It is difficult to change this decision after you run setup. Hmmm. I'm not sure what drove us to make this statement in the documentation, as making this transition is actually quite simple and straightforward. I *think* that it might have been the fact that CIFS has to be stopped and restarted to move from workgroup mode into domain mode (or vice versa), thus temporarily and briefly disrupting file service to Windows clients. However, if you can arrange to make the transition at a time of low usage (the small hours of the morning for example), the disruption should have minimal impact. The whole operation should take just a few minutes. You need to execute a "cifs terminate" followed by another "cifs setup" and then you're basically done. ><gulp> Okay, I do want to change (from a workgroup to a domain). Good move! :-) >How difficult is "difficult"? As I mentioned, not very (aside from the brief service disruption). >How does changing the authentication method from NIS to a domain >controller affect the UNIX boxes accessing the filer via NFS? It doesn't. However, if you do start creating NTFS or MIXED mode file systems after making the transition, you may need to take a look at how UNIX security is effected by the use of these modes. There are two papers in the "Technology" section of our web site that explain these issues quite well. If you stick with UNIX mode file systems however, you have absolutely no reason to be concerned about how the new domain mode of CIFS effects NFS, because it doesn't. Keith

3 3

Re: CIFS share access?
by Alexander Strauss 11 Mar '99

11 Mar '99

Graham, this only works if the Unix home has the same name as the NT username ... a workaround would be to create symlinks. Thank you, Alex "Graham C. Knight" wrote: > > Try setting your cifs.home_dir option > to /path/unix_homes > > That will allow users to map their directories > as \\filer\username > > There a re a bunch of acveats with using > the cifs.home_dir option though - the main > one being that there can only be one > cifs.home_dir mount point per filer. The > second one being that users can only mount their > own home directories with this method - they cannot > mount other peoples homes. > > Graham > > Alexander Strauss wrote: > > > > Hello, > > > > I shared the directory where most of our Unix-Homes are located under > > the CIFS sharename UNIX_HOMES. There's no problem to connect > > \\filer\unix_homes, but I cannot connect directly to a sub-directory, > > i.e. \\filer\unix_homes\alex. > > > > Is this way to connect not implemented or is it a configuration problem? > > > > thank you, > > -- > > Alexander Strauss - Email: strauss(a)ti.com - TI-MSG: ALST > > System Administrator - Mixed Signal & Logic Products Europe > > Texas Instruments Deutschland GmbH, 85350 Freising, Germany > > Phone: +49 8161 80-3606 - Fax: +49 8161 80-4477 -- Alexander Strauss - Email: strauss(a)ti.com - TI-MSG: ALST System Administrator - Mixed Signal & Logic Products Europe Texas Instruments Deutschland GmbH, 85350 Freising, Germany Phone: +49 8161 80-3606 - Fax: +49 8161 80-4477

1 0

CIFS share access?
by Alexander Strauss 11 Mar '99

11 Mar '99

Hello, I shared the directory where most of our Unix-Homes are located under the CIFS sharename UNIX_HOMES. There's no problem to connect \\filer\unix_homes, but I cannot connect directly to a sub-directory, i.e. \\filer\unix_homes\alex. Is this way to connect not implemented or is it a configuration problem? thank you, -- Alexander Strauss - Email: strauss(a)ti.com - TI-MSG: ALST System Administrator - Mixed Signal & Logic Products Europe Texas Instruments Deutschland GmbH, 85350 Freising, Germany Phone: +49 8161 80-3606 - Fax: +49 8161 80-4477

2 1

Shelves, disks, et al
by Stephen C. Woods 11 Mar '99

11 Mar '99

I've got a couple of questions for the list. (1) Can 9 GB drives be used in the same type shelves as 4 GB drives? I'm talking about narrow drives here. (2) Can they be mixed (4 and 9 GB drives) in a shelf? How about on the same controller? (3) Is there any source for drives other than Netapps? (4) If one obtains drives from another source can they be put under support (yeah I know, fat chance)? Would they void current hardware support? Would they void software support? (5) If I had some extra narrow shelves is there a market? We're thinking about decommissioning one of our older filers. Reply-to set to the list, as I'll bet dollars to doughnuts that other folks are interested. Thanks in advance Steve Woods

2 1

RE: Accessing CIFS shares with Unix authentication
by Will Harper 11 Mar '99

11 Mar '99

I can't answer your question directly, but I have "heard" that CIFS is a problem. It works ok, when it is working, but when it hiccups, it is not easily corrected. When a CIFS connection is broken, it stays broken. A vendor's engineer (Auspex) told me that he had found that an NFS client on NT actually provided better end results for all of the H-A storage systems that he had worked with. He suggested Samba or Hummingbird. NFS, he explained, keeps trying to reconnect until you fix the problem, and then NFS fixes itself. Will Harper, MCSE -----Original Message----- From: P.S.Jones [SMTP:P.S.Jones@durham.ac.uk] Sent: Wednesday, March 10, 1999 11:01 AM To: toasters(a)mathworks.com Subject: Accessing CIFS shares with Unix authentication We have a Network Appliance 740 Filer for evaluation and want to try it in a mixed Unix and NT environment. I think we can handle the Unix side without any real problems. What we are struggling with is how to provide access to the CIFS file store to our NT clients by supplying Unix credentials? I'll explain this in a bit more detail. Our NT service has no user accounts, or rather it has one, a general auto logon account. Within this account's logon script we prompt for authentication details (real user ID and password) and then map network shares against our existing Netware 3.1 servers. In the summer we plan to retire Netware 3.1 and provide the home file store from a Unix like system. We've tried Samba and quite like it but we want to evaluate the Filer as well. But how can we map a CIFS share from the Filer using just Unix credentials? I'm trying to read the documentation at the moment and have come across the usermap.cfg file mechanism, but this doesn't seem quite appropriate since we don't have any NT accounts. I wonder if anyone on this list has solved a problem like this? Are we going to have to run Samba anyway for the authentication? Any comments gratefully received. -- Paul Jones, ITS, University of Durham, South Road, Durham DH1 3LE Email: P.S.Jones(a)durham.ac.uk Phone/Fax: 0191 374 2879/3741

4 4

Re: Accessing CIFS shares with Unix authentication
by Mark Muhlestein 10 Mar '99

10 Mar '99

>At 01:25 pm 3/10/99 -0500, Will Harper wrote: >>I can't answer your question directly, but I have "heard" that CIFS is a >>problem. It works ok, when it is working, but when it hiccups, it is not >>easily corrected. When a CIFS connection is broken, it stays broken. >> >>A vendor's engineer (Auspex) told me that he had found that an NFS client >>on NT actually provided better end results for all of the H-A storage >>systems that he had worked with. He suggested Samba or Hummingbird. NFS, >>he explained, keeps trying to reconnect until you fix the problem, and then >>NFS fixes itself. Samba? Samba is a CIFS server. As Dave Hitz pointed out, there are tradeoffs with the various protocols, but with a Netapp box you can use whichever suits your needs best. Mark Muhlestein -- mmm(a)netapp.com

1 0

Re: Accessing CIFS shares with Unix authentication
by Jason D. Kelleher 10 Mar '99

10 Mar '99

In message <01BE6AF9.7FE779F0.willh(a)infi.net>, Will Harper writes: >I can't answer your question directly, but I have "heard" that CIFS is a >problem. It works ok, when it is working, but when it hiccups, it is not >easily corrected. When a CIFS connection is broken, it stays broken. > >A vendor's engineer (Auspex) told me that he had found that an NFS client >on NT actually provided better end results for all of the H-A storage >systems that he had worked with. He suggested Samba or Hummingbird. NFS, >he explained, keeps trying to reconnect until you fix the problem, and then >NFS fixes itself. > >Will Harper, MCSE Auspex told us the same... right before they mentioned that CIFS wasn't supported for partitions under ClusterGuard(tm) -- their shared disk failover option. Not that I disagree... I really like the the statelessness (not sure if that's a word) of NFS. Any truth to the legend that NFS kept state, but was changed because the stability of the servers was questionable? jason

1 0

NFS fundamentally broken ???
by Philip Thomas 10 Mar '99

10 Mar '99

Hi, An experienced sys admin and a colleague of mine argue that NFS is "fundamentally broken", in the sense that because of it's stateless architecture, a NFS client can "hang" during shutdown if it's NFS server(s) does not respond. This is aggravated when an "ack" is lost between server/client. He claims to have gone through NFS code while he was at a prestigious university. Granted I am not an expert, all the years I have worked with NFS, I never had a problem shutting down a system because it's NFS mount was not "responding". But I am hoping for folks with "theoretical" background to shed some more light into the above argument. This brings to the second question. The same person emphasize the above issue as an added reason for not having NFS mount points on his HP High Availability (ServiceGuard). Is there any site out there, in this wide world, using HP's ServiceGuard (or any other HA) on a system that is an NFS client and would like to comment on their experience in private or in this forum. Philip Thomas Motorola - PEL, M/S M350 2200 W. Broadway M350 Mesa, AZ 85202 rxjs80(a)email.sps.mot.com (602) 655-3678 (602) 655-2285 (fax)

1 0

RE: Accessing CIFS shares with Unix authentication
by Sam Schorr 10 Mar '99

10 Mar '99

Will, It is not true that CIFS connections "stay broken" as you state. We are exclusively a CIFS environment and we have frequent CIFS disconnects. There are a number of reasons for this, and it is true that CIFS behaves very differently then NFS. However, I think Auspex has a lot to prove when it makes the NFS claim of better "results" whatever, that means. A CIFS client will reconnect automatically to the CIFS share as long as that share remains available to the NT domain. -----Original Message----- From: Will Harper [mailto:willh@infi.net] Sent: Wednesday, March 10, 1999 10:26 AM To: 'P.S.Jones'; toasters(a)mathworks.com Subject: RE: Accessing CIFS shares with Unix authentication I can't answer your question directly, but I have "heard" that CIFS is a problem. It works ok, when it is working, but when it hiccups, it is not easily corrected. When a CIFS connection is broken, it stays broken. A vendor's engineer (Auspex) told me that he had found that an NFS client on NT actually provided better end results for all of the H-A storage systems that he had worked with. He suggested Samba or Hummingbird. NFS, he explained, keeps trying to reconnect until you fix the problem, and then NFS fixes itself. Will Harper, MCSE -----Original Message----- From: P.S.Jones [SMTP:P.S.Jones@durham.ac.uk] Sent: Wednesday, March 10, 1999 11:01 AM To: toasters(a)mathworks.com Subject: Accessing CIFS shares with Unix authentication We have a Network Appliance 740 Filer for evaluation and want to try it in a mixed Unix and NT environment. I think we can handle the Unix side without any real problems. What we are struggling with is how to provide access to the CIFS file store to our NT clients by supplying Unix credentials? I'll explain this in a bit more detail. Our NT service has no user accounts, or rather it has one, a general auto logon account. Within this account's logon script we prompt for authentication details (real user ID and password) and then map network shares against our existing Netware 3.1 servers. In the summer we plan to retire Netware 3.1 and provide the home file store from a Unix like system. We've tried Samba and quite like it but we want to evaluate the Filer as well. But how can we map a CIFS share from the Filer using just Unix credentials? I'm trying to read the documentation at the moment and have come across the usermap.cfg file mechanism, but this doesn't seem quite appropriate since we don't have any NT accounts. I wonder if anyone on this list has solved a problem like this? Are we going to have to run Samba anyway for the authentication? Any comments gratefully received. -- Paul Jones, ITS, University of Durham, South Road, Durham DH1 3LE Email: P.S.Jones(a)durham.ac.uk Phone/Fax: 0191 374 2879/3741

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters