toasters

toasters@lists.teaparty.net

13515 discussions

Disk Controller Failures
by Mingway Huang 25 Jun '99

25 Jun '99

Hi there, We recently encountered a disk controller failure on one of our data servers (not on our Netapp). The problem was that this failure was not a complete failure of the drive itself, but rather the controller started to die slowly. (i.e. handles some request sometimes and other times who knows?) As a result, this caused our entire filesystem to become corrupt and we lost some of our data as a result. Although this filesystem was mirrored, this did not help us at all, as it was considered a logical error in the filesystem and not a hardware problem. My question is that should this occur on a Netapps (this may even apply to any other Enterprise server) would it cause the entire filesystem to go corrupt and cause partial or complete data loss as in this case? Mingway Huang Nortel Networks

1 0

RE: list of file lock types
by Hawley, Rob 23 Jun '99

23 Jun '99

CIFS locks have two parts; basically "What I want to Do" and "What I am going to prevent others from doing". "What I want to Do" EXEC == read + execute R&W == read + write Read read Write write "What I am going to prevent others from doing". DenyAll exclusive access to file DenyR others cannot read the file, but can write DenyW others cannot write file, but can read DenyN others can read or write the file DOS special compatibility mode for DOS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > mailto: hawleyr(a)netapp.com <mailto:hawleyr@netapp.com> US Mail: Network Appliance Inc. > Phone: 408-822-6661 2770 San Tomas Expressway > FAX: 408-822-4521 Santa Clara, CA 95051 -----Original Message----- From: Todd C. Merrill [mailto:tmerrill@mathworks.com] Sent: Tuesday, June 22, 1999 2:24 PM To: toasters(a)mathworks.com Subject: list of file lock types When you do a 'cifs sessions host/user', you get a list like: users shares/files opened machine (user) share Exec-denyW \path R&W-denyAll \path Read-denyAll \path Read-denyN \path Read-denyW \path Write-denyN \path Write-denyW \path Where can I find a comprehensive list of these locks, and what they mean? Most are self-explanatory; but, for instance, what is "N" stand for? NetApp Release 5.2.1P2: Tue Mar 16 10:41:03 PST 1999 Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

2 1

RE: quick question about dumping snapshots
by Melvin, Grant 23 Jun '99

23 Jun '99

Hi Jason, > Hmmm... It seems to be _another_ NDMP bug. The first example I > sent out was generated by running the dump from BudTool via NDMP. This is a bug and its been filed as 15998, the following description will be online tomorrow: TITLE: ndmpd updates the dumpdates table incorrectly when dumping pre-existing snapshots DESCRIPTION: In 5.3, if a dump of a pre-existing snapshot (such as /vol/vol0/.snapshot/hourly.0) is used, the dumpdates table is updated without the ".snapshot/hourly.0". It should only show: /vol/vol0/ 0 Sun Jan 1 00:00:00 1999 However, ndmpd prints out /vol/vol0/.snapshot/hourly.0 0 Sun Jan 1 00:00:00 1999 to the dumpdates table and doesn't modify the dump name to "/vol/vol0/". Sorry for the inconvenience. Cheers, Grant

1 0

help on quotas
by Jason Middlebrooks 23 Jun '99

23 Jun '99

I have the following happening. Overview: F630 running OnTap 5.2.2 using CIFS. Two volumnes vol0 and usr. The volume usr contains everybody home directories using cifs.home_dir. I am using a PDC for authentication and I am not using the passwd or group files on the filer. Whats Happening: I have a quota file with the following entries: /vol/usr/usrhomes/cnievesad user@/vol/usr 5G 20K * user@/vol/usr 80M 15K # Default home directory quota /vol/vol0/trafficker tree 5G 15K /vol/vol0/prod tree 2GB 15K /vol/vol0/tsa tree 4GB 50K I have created a new user called msmith and I created the following directory /vol/usr/userhomes/msmith. msmith can map to his directory fine but when I try to create a new folder or file I get the following messages on the filer: Wed Jun 23 14:34:06 GMT [wafl_lopri]: uid 65534: disk quota exceeded on volume usr. The default home directory quota has working in the past at least when I was at OnTap 5.0 Any ideas??? Thanks in advance Jason

1 0

RE: help on quotas
by Benn, Paul 23 Jun '99

23 Jun '99

For quotas to work properly, you will need to setup and maintain an /etc/passwd and an /etc/group file. We're working on a better document specific to quotas but you can have a quick look at section 5.2 in the following document: http://www.netapp.com/technology/level3/3053.html#Sect5.2 Since quotas are based the UID and since you appear to have a CIFS-only filer, each file's UNIX owner needs to be changed to reflect the correct user name instead of "pcuser." I should have a work-around (the document referenced above) posted on the now site in the next week or so. This should be enough info to get it up and running so you can play around with quotas. Best regards, Paul -----Original Message----- From: Jason Middlebrooks [mailto:Jason_Middlebrooks@datalink.com] Sent: Wednesday, June 23, 1999 9:07 AM To: toasters(a)mathworks.com Subject: help on quotas I have the following happening. Overview: F630 running OnTap 5.2.2 using CIFS. Two volumnes vol0 and usr. The volume usr contains everybody home directories using cifs.home_dir. I am using a PDC for authentication and I am not using the passwd or group files on the filer. Whats Happening: I have a quota file with the following entries: /vol/usr/usrhomes/cnievesad user@/vol/usr 5G 20K * user@/vol/usr 80M 15K # Default home directory quota /vol/vol0/trafficker tree 5G 15K /vol/vol0/prod tree 2GB 15K /vol/vol0/tsa tree 4GB 50K I have created a new user called msmith and I created the following directory /vol/usr/userhomes/msmith. msmith can map to his directory fine but when I try to create a new folder or file I get the following messages on the filer: Wed Jun 23 14:34:06 GMT [wafl_lopri]: uid 65534: disk quota exceeded on volume usr. The default home directory quota has working in the past at least when I was at OnTap 5.0 Any ideas??? Thanks in advance Jason

1 0

quick question about dumping snapshots
by Jason D. Kelleher 23 Jun '99

23 Jun '99

According to NOW, backing up from a snapshot should place the "real" path in /etc/dumpdates: NOW: Knowledge Base: Data ONTAP: Backup and Recovery: Backing up the Filer to Tape: FAQ_575 Q: How do I dump an already-created snapshot? A: Essentially, you only need to specify the snapshot in the dump path. For example, to dump the hourly.0 snapshot, run: dump 0uf rst0a /vol/vol0/.snapshot/hourly.0/rest_of_path In pre-Data ONTAP 5.1 releases, the /etc/dumpdates table entry will look like: /vol/vol0/.snapshot/hourly.0/rest_of_path 0 Tue Jul 28 20:39:46 1998 In post-5.1 releases, the /etc/dumpdates table entry will look like: /vol/vol0/rest_of_path 0 Tue Jul 28 20:39:46 1998 Note that if you are running a pre-multi-volume release (pre-5.0, in other words), the command will look like: dump 0uf rst0a /.snapshot/hourly.0/rest_of_path I'm running DOT 5.3D9. So am I doing something wrong, or is this just another example of bad documentation from NetApp? blacklodge: ~ [635] # grep test /net/bonnie/vol/fs0/etc/dumpdates /vol/fs0/home/test 1 Mon Jun 21 23:49:09 1999 /vol/fs0/home/test 0 Sat Jun 19 01:29:01 1999 blacklodge: ~ [636] # blacklodge: ~ [636] # blacklodge: ~ [636] # grep test /net/bonnie/vol/fs0/etc/dumpdates /vol/fs0/home/test 1 Mon Jun 21 23:49:09 1999 /vol/fs0/home/test 0 Sat Jun 19 01:29:01 1999 /vol/fs0/.snapshot/hourly.0/home/test 0 Tue Jun 22 08:00:54 1999 blacklodge: ~ [637] #

2 2

New 760
by Ron Neuenberger 23 Jun '99

23 Jun '99

If anyone has received a new 760 with the on board fibre channel, make sure your SE had an additional fibre card available as a spare. They are have serious problems with the onboard fibre cards and they don't have any replacement at this time. I have lost 2 now and am waiting for a replacement, meanwhile I am down. Just didn't want this to happen to anyone else.

4 3

list of file lock types
by Todd C. Merrill 22 Jun '99

22 Jun '99

When you do a 'cifs sessions host/user', you get a list like: users shares/files opened machine (user) share Exec-denyW \path R&W-denyAll \path Read-denyAll \path Read-denyN \path Read-denyW \path Write-denyN \path Write-denyW \path Where can I find a comprehensive list of these locks, and what they mean? Most are self-explanatory; but, for instance, what is "N" stand for? NetApp Release 5.2.1P2: Tue Mar 16 10:41:03 PST 1999 Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

2 1

netcache on a F500 series
by kelvin 22 Jun '99

22 Jun '99

Dear all, quick question, is there any way to turn off the caching (other than putting a global url stoplist), and just allowing the netapp box to be a dedicated proxy, rather than a caching proxy? swift responses appreciated, many thanks, kelvin tooth

4 3

Microsoft Access
by Mark D. Fowle 22 Jun '99

22 Jun '99

Retain Until: 07/22/99 Retention Category: G90 - Information and Reports Has anyone had any problems running any Access applications from the NetApps ? Our NT Admin says the apps run fine on NT but when they are on the netapps the lock up (cifs.lock is disabled on the flier --) Are there any NT admins out there experiencing problems that you have not been able to get solutions for ? I feel the Netapps box is great .. but I am slowly becoming the only one at this site that does .... Any information would be helpful. Thanks. Mark Fowle Unix/Metaphase Administration Caterpillar

1 0

RE: Windows NT Resource Kit partial contents
by Patrick.Day.B＠bayer.com 21 Jun '99

21 Jun '99

One Word: SuperCACLS. We have used the SuperCACLS suite and are extremely happy with it. Not only does it handle the ACL's including forcing ownership changes, it is relatively dirt cheap. www.trustedsystems.com. --Patrick Day Sys Admin Bayer Corp. owner-toasters(a)mathworks.com on 06/21/99 02:10:04 PM To: tkaczma(a)gryf.net @ INTERNET cc: "DDA.RFC-822=toasters(a)mathworks.com/P=Internet/A= /C=us"@X400 Subject: RE: Windows NT Resource Kit partial contents I'm happy you were able to get the NT reskit chown to work. In the spirit of collegiality that so far has pervaded the toasters list, perhaps you could provide an example of how you did it? As far as I can see the "F-ing Manual" (in this case the "F" is richly deserved) says little more about chown other than to state that it is present. And I already gave an example of the "usage" output when no arguments are supplied. Can you give me a pointer to the manual or help file or doc file for this? Ever curious, I downloaded the sources for the NT POSIX commands, and chown.exe just uses the NT POSIX subsystem "chown()" call which takes a 32 bit numeric UID. It is hard to see how that can be used to set the normal NT security information. I am curious how you were able to use that chown to help administer NT boxes. Are you positive it wasn't the MKS toolkit chown? And if you did do it, were you able to set the owner to something other that yourself (i.e. other than a "take ownership")? The sources did solve the mystery of why the "usage" was asking for a group: the chown and chgrp commands use the same executable, and the command looks at the third byte of the command to see if it is "o" (lower case only) to see if it's chown or chgrp. I was typing "f:chown", so the third byte was 'c'. As I said, these NT POSIX commands are pretty crude. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: tkaczma(a)gryf.net [mailto:tkaczma@gryf.net] Sent: Sunday, June 20, 1999 11:34 AM To: toasters(a)mathworks.com Subject: RE: Windows NT Resource Kit partial contents On Sat, 19 Jun 1999, Muhlestein, Mark wrote: > You're right! I forgot about the NT POSIX tools. But I was unable to ever get > the 'chown' command to work. This stuff is pretty crude. MKS Toolkit is far > superior. Has anyone ever gotten the NT reskit 'chown' to work? Here's what I > get from the very latest version: I had it working even programatically, in the times when I was foolish enough to administer NT boxes. I can say one thing, I'm glad I went back to my roots before this Melissa and other e-mail worms poop hit the fan. My advice on getting chown to work: RTFM. Tom

1 0

RE: Windows NT Resource Kit partial contents
by Muhlestein, Mark 21 Jun '99

21 Jun '99

I'm happy you were able to get the NT reskit chown to work. In the spirit of collegiality that so far has pervaded the toasters list, perhaps you could provide an example of how you did it? As far as I can see the "F-ing Manual" (in this case the "F" is richly deserved) says little more about chown other than to state that it is present. And I already gave an example of the "usage" output when no arguments are supplied. Can you give me a pointer to the manual or help file or doc file for this? Ever curious, I downloaded the sources for the NT POSIX commands, and chown.exe just uses the NT POSIX subsystem "chown()" call which takes a 32 bit numeric UID. It is hard to see how that can be used to set the normal NT security information. I am curious how you were able to use that chown to help administer NT boxes. Are you positive it wasn't the MKS toolkit chown? And if you did do it, were you able to set the owner to something other that yourself (i.e. other than a "take ownership")? The sources did solve the mystery of why the "usage" was asking for a group: the chown and chgrp commands use the same executable, and the command looks at the third byte of the command to see if it is "o" (lower case only) to see if it's chown or chgrp. I was typing "f:chown", so the third byte was 'c'. As I said, these NT POSIX commands are pretty crude. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: tkaczma(a)gryf.net [mailto:tkaczma@gryf.net] Sent: Sunday, June 20, 1999 11:34 AM To: toasters(a)mathworks.com Subject: RE: Windows NT Resource Kit partial contents On Sat, 19 Jun 1999, Muhlestein, Mark wrote: > You're right! I forgot about the NT POSIX tools. But I was unable to ever get > the 'chown' command to work. This stuff is pretty crude. MKS Toolkit is far > superior. Has anyone ever gotten the NT reskit 'chown' to work? Here's what I > get from the very latest version: I had it working even programatically, in the times when I was foolish enough to administer NT boxes. I can say one thing, I'm glad I went back to my roots before this Melissa and other e-mail worms poop hit the fan. My advice on getting chown to work: RTFM. Tom

1 0

RE: Windows NT Resource Kit partial contents
by Muhlestein, Mark 20 Jun '99

20 Jun '99

You're right! I forgot about the NT POSIX tools. But I was unable to ever get the 'chown' command to work. This stuff is pretty crude. MKS Toolkit is far superior. Has anyone ever gotten the NT reskit 'chown' to work? Here's what I get from the very latest version: C:\WTSRV\Profiles\mmm.000>f:chown usage: f:chown [-Rf] group file ... C:\WTSRV\Profiles\mmm.000>f:chown nt-domain\tgroup xx f:chown: unknown group id: nt-domain/tgroup Maybe it would work if it were running in a POSIX NT subsystem. And why does it say you should supply a group? If someone wants to dig into it and figure out why it doesn't work that would be good. In the meantime, as I mentioned before, there are other programs like "subinacl" and "cacls" that I know do work to natively manipulate the NT security settings. Mark -----Original Message----- From: tkaczma(a)gryf.net [mailto:tkaczma@gryf.net] Sent: Friday, June 18, 1999 10:26 PM To: toasters(a)mathworks.com Subject: Windows NT Resource Kit partial contents For those of us who are unfamiliar with the contents of the NT RK, here is the info from WHGIII's playground: ---- Microsoft Windows NT Questions and Answers How can I ease the transition from UNIX to Microsoft Windows NT? There are a several utilities in the Windows NT Resource Kit that will be familiar to the UNIX user. Among them are: ar.exe, cat.exe, cc.exe, chmod.exe, chown.exe, cp.exe, devsrv.exe, find.exe, grep.exe, ld.exe, ln.exe, ls.exe, make.exe, mkdir.exe, mv.exe, rm.exe, rmdir.exe, sh.exe, touch.exe, vi.exe, and wc.exe. When using these from the DOS shell you do not need to type the file extension. When in the 'sh' shell the extensions must be used. Please note that these files execute in upper case. Once SH.EXE has been started, an alias can be created to change case and form e.g. alias cat=CAT.EXE. These utilities will allow you to leverage your UNIX script file investment. ---- Source: http://www.microsoft.com/SalesInfo/QA/QA5909.HTM

2 1

RE: CIFS Administrators vs file ownership
by Muhlestein, Mark 19 Jun '99

19 Jun '99

Have you tried using the "/o" option of scopy? That should copy the owner information, and the mapped UNIX owner should show up correctly. One thing to keep in mind is that if a file has NTFS-style security the UNIX perms are only display perms. The actual permission checking is always done using the ACL. NFS accesses use the mapped NT account to check access of files with ACLs. (And of course, files with UNIX-style security always use the UNIX identity, native or mapped.) Again, many of these questions are answered in the 5.3 security troubleshooter: http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/index.s… Good luck, Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Gregory M. Paris [mailto:paris@bose.com] Sent: Saturday, June 19, 1999 10:01 AM To: toasters(a)mathworks.com Cc: paris(a)bose.com Subject: Re: CIFS Administrators vs file ownership Toasters, Happily, the answer to my question was simple indeed (given that we're running a 5.3 variant of OnTap). The answer was supplied by a helpful NetApp employee, who apparently didn't cc the list with the answer, so I'll repeat it here: options wafl.nt_admin_priv_map_to_root off This allows me to have administrative access with my usual NT account (by virtue of membership in Domain Admins), yet files created by my NT account are owned by my UNIX account (not root) on the UNIX side. Really, it does seem to be the cake I was looking to have and eat, since on the NT side, the ownership of such files is FILER\Administrators, as would be expected. I must say that the documentation on this option is a bit terse. True, the name of the option is almost long enough to be self-documenting :-), but the description of exactly what the option does and why one might fiddle with it needs some fleshing out. Now all we have to do is fix all my users' NT files, since they're all owned by Administrators (root on the UNIX side) when we scopy them over to the filer. Perhaps the chown command is the solution here.... Any thoughts? Thanks everybody for your help. Greg -- Gregory M. Paris CIS Engineering Systems Bose Corporation Email: paris(a)bose.com The Mountain Phone: +1 508 766-6080 Framingham, MA 01701-9168 FAX: +1 508 820-0173

1 0

Re: CIFS Administrators vs file ownership
by Gregory M. Paris 19 Jun '99

19 Jun '99

Toasters, Happily, the answer to my question was simple indeed (given that we're running a 5.3 variant of OnTap). The answer was supplied by a helpful NetApp employee, who apparently didn't cc the list with the answer, so I'll repeat it here: options wafl.nt_admin_priv_map_to_root off This allows me to have administrative access with my usual NT account (by virtue of membership in Domain Admins), yet files created by my NT account are owned by my UNIX account (not root) on the UNIX side. Really, it does seem to be the cake I was looking to have and eat, since on the NT side, the ownership of such files is FILER\Administrators, as would be expected. I must say that the documentation on this option is a bit terse. True, the name of the option is almost long enough to be self-documenting :-), but the description of exactly what the option does and why one might fiddle with it needs some fleshing out. Now all we have to do is fix all my users' NT files, since they're all owned by Administrators (root on the UNIX side) when we scopy them over to the filer. Perhaps the chown command is the solution here.... Any thoughts? Thanks everybody for your help. Greg -- Gregory M. Paris CIS Engineering Systems Bose Corporation Email: paris(a)bose.com The Mountain Phone: +1 508 766-6080 Framingham, MA 01701-9168 FAX: +1 508 820-0173

1 0

Re: Backup
by sirbruce＠ix.netcom.com 19 Jun '99

19 Jun '99

On 06/18/99 09:02:37 you wrote: >I am experiencing a problem with dump since upgrading the filers to >5.2.2. I contacted Netapp for help as you can see below. Netapp >is still working on this problem and said no one has reported anything >like this and this is first of its kind. This bug is described on NOW. >Netapp cannot duplicate the >problem because they don't have autoloader inhouse. Since when??? >I was hoping perhap >you can contact some of your customers who has a simular setup as I do >here. I have a DLT4700 connected to a filer. I wish they had emailed me before they got rid of the DLT4700s they had; I would have taken them off their hands. I would try talking to a different support person who knows what they are talking about. Bruce

2 1

Re: Windows NT Resource Kit partial contents
by sirbruce＠ix.netcom.com 19 Jun '99

19 Jun '99

On 06/19/99 00:26:03 you wrote: >There are a several utilities in the Windows NT Resource Kit that will be >familiar to the UNIX user. Among them are: > >devsrv.exe As a UNIX user I can't say I'm familiar with this one. Bruce

2 1

Windows NT Resource Kit partial contents
by tkaczma＠gryf.net 19 Jun '99

19 Jun '99

For those of us who are unfamiliar with the contents of the NT RK, here is the info from WHGIII's playground: ---- Microsoft Windows NT Questions and Answers How can I ease the transition from UNIX to Microsoft Windows NT? There are a several utilities in the Windows NT Resource Kit that will be familiar to the UNIX user. Among them are: ar.exe, cat.exe, cc.exe, chmod.exe, chown.exe, cp.exe, devsrv.exe, find.exe, grep.exe, ld.exe, ln.exe, ls.exe, make.exe, mkdir.exe, mv.exe, rm.exe, rmdir.exe, sh.exe, touch.exe, vi.exe, and wc.exe. When using these from the DOS shell you do not need to type the file extension. When in the 'sh' shell the extensions must be used. Please note that these files execute in upper case. Once SH.EXE has been started, an alias can be created to change case and form e.g. alias cat=CAT.EXE. These utilities will allow you to leverage your UNIX script file investment. ---- Source: http://www.microsoft.com/SalesInfo/QA/QA5909.HTM

1 0

RE: CIFS Administrators vs file ownership
by Muhlestein, Mark 19 Jun '99

19 Jun '99

Actually, I don't think there is a "chown" in the NT reskit (as it is called by the cognoscenti :-), but there is a command called "subinacl.exe" which allows you to do various manipulations of the NT security information on files, including changing ownership. NT security folks make much of the fact that administrator privilege does not allow you to set ownership, only take it, the idea being that you can't cover your tracks if you operate on a file as administrator that you had been blocked from via an ACL. However, it turns out that you really need to do this from time to time, so there are ways to do it if you need to, as long as you have the 'backup' and 'restore' NT privileges, which Admins have by default. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: tkaczma(a)gryf.net [mailto:tkaczma@gryf.net] Sent: Friday, June 18, 1999 7:56 PM To: toasters(a)mathworks.com Subject: Re: CIFS Administrators vs file ownership On Fri, 18 Jun 1999, Keith Brown wrote: > So.... I'll fire you my "ntchown" tool under separate cover. You'll be my > second customer for it. I haven't exactly "tested the living daylights out > of it", but I'm pretty confident it works under most scenarios, as it's > really very simple. BTW, I think there is a chown in the NT Server (?) Resource Kit, which in my opinion should have been a part of the NT Server package. If the Exploder is a part of the OS such tools certainly are. However, as I recall there might have been a problem in the fact that the ACLs would be screwed up (owner/creator permissions, etc. would be different then expected) after chowning a file. Tom

2 1

RE: Named Pipes?
by Muhlestein, Mark 19 Jun '99

19 Jun '99

The important point is that if a CIFS client is trying to open a named pipe on a server it means that it is trying to connect to a piece of software running on that server, since NT named pipes are not filesystem objects, but rather are created by server applications. Since the filer does not run NT apps, that will fail. The way Oracle on NT works is that you have an Oracle instance running on an NT server, and the Oracle clients use some protocol to connect to the Oracle server. If you want to use the filer for the back-end storage, you tell the Oracle server to use a remote disk resource, which results in a CIFS connection to the filer. Here is a write-up that may have some useful details for anyone looking at using a filer as a back-end for an NT database: http://www.netapp.com/technology/level3/3048.html Good luck, Mark Muhlestein -- mmm(a)netapp.com BTW Tom that overview of named pipes I was looking for is at http://msdn.microsoft.com/library/sdkdoc/winbase/pipes_6nqr.htm -----Original Message----- From: tkaczma(a)gryf.net [mailto:tkaczma@gryf.net] Sent: Friday, June 18, 1999 7:44 PM To: toasters(a)mathworks.com Subject: RE: Named Pipes? On Thu, 17 Jun 1999, Muhlestein, Mark wrote: > On NT an application on the server side has to open a named > pipe in order for it to be used. With NT there is no way for two different > clients to 'open' a named pipe on a third box like you can with a UNIX named > pipe special device. I have never said this. That is what you implied. I said that you place the named pipe on the NFS filesystem and then if you access it through the same mount on the same machine it will take data from one process to another. I said that that was all that would happen as far as I knew. As for NT I said that I would not know where to begin to open a named pipe. However, if NTFS (CIFS/SMB really) supports writing named pipes it should work whether the CIFS volume is on a real NT server or a real (tic) Network Appliance. > The named pipe is actually created by the server app and > does not have an independent existence. If it doesn't have an existence aside from the server app then what is the point of putting it on a filesystem. Filesystems are usually designed to hold persistent data. > For some background on NT named pipes see > > http://support.microsoft.com/support/kb/articles/Q101/1/50.asp > http://support.microsoft.com/support/kb/articles/Q126/7/66.asp I read the first one, and now understand your skew. What you should have really said is that the named pipes will not be stored on the CIFS filesystem and thus the question is irrelevant. The server running the database will create the named pipe as a resource separate from the filesystem storing the database. If the database clients connecting to the server require that the named pipe and the database file reside on the same host (I don't see why the clients should look at the file at all, but some old decripid databases have no concept of server only cooperating clients) then this will not work. However, I venture to say that this is not the case and in theory if you (the original poster) can keep the database file on another NT server you should be able to keep that file on the NetApp as well with no problems. Bear in mind that, as our colleague Mark said, the NetApp is not a database server and will not act as one. You should trreat a NetApp as a very intelligent disk, that is all that it is, a file server. > There are better ones than these, but while I was looking for them Microsoft's > web site went down... If you find them please jot me a note, I'm curious about this stuff. BTW, with NT there is a way to open a named pipe between 2 processes on 2 different boxes, with UNIX it must be on the same system and mount point AFAICT. Tom

1 0

CIFS Administrators vs file ownership
by Gregory M. Paris 19 Jun '99

19 Jun '99

Toasters, We've recently received our first filer, an F740 with NFS and CIFS. We're in the process of working out all the issues and procedures before we deploy the device. The issue we're struggling with at the moment involves people with NT Administrator access. In the NT world, we admins are used to having accounts with Administrator access (by virtue of being Domain Admins). It never matters to us that our files get created with ownership of "Administrators". In the UNIX world, we're used to using "su" to get root access when we need it. All of our own files are owned by our respective accounts, not root. We intend to merge our UNIX and NT home directories, but life is not smooth for we admins. When we create files on the filer from the NT world, they're owned by Administrator; that's OK. But on the UNIX side, they show up as being owned by root; that's not. We'd like to have our admin access cake and eat it too. In other words, what we'd like is to have our NT Administrator access, but have files get created with our respective ownerships, not root's. How do the rest of you work this issue? Greg -- Gregory M. Paris CIS Engineering Systems Bose Corporation Email: paris(a)bose.com The Mountain Phone: +1 508 766-6080 Framingham, MA 01701-9168 FAX: +1 508 820-0173

3 2

Spares kits.
by Shaun T. Erickson 19 Jun '99

19 Jun '99

Do the F720, F740 & F760 filers use the same spares kit, or are there different ones for each one? -ste -- Work: (908) 582-7629 Pager: (800) 756-1133 Cell: (201) 310-9941

2 4

RE: Named Pipes?
by tkaczma＠gryf.net 19 Jun '99

19 Jun '99

On Thu, 17 Jun 1999, Muhlestein, Mark wrote: > On NT an application on the server side has to open a named > pipe in order for it to be used. With NT there is no way for two different > clients to 'open' a named pipe on a third box like you can with a UNIX named > pipe special device. I have never said this. That is what you implied. I said that you place the named pipe on the NFS filesystem and then if you access it through the same mount on the same machine it will take data from one process to another. I said that that was all that would happen as far as I knew. As for NT I said that I would not know where to begin to open a named pipe. However, if NTFS (CIFS/SMB really) supports writing named pipes it should work whether the CIFS volume is on a real NT server or a real (tic) Network Appliance. > The named pipe is actually created by the server app and > does not have an independent existence. If it doesn't have an existence aside from the server app then what is the point of putting it on a filesystem. Filesystems are usually designed to hold persistent data. > For some background on NT named pipes see > > http://support.microsoft.com/support/kb/articles/Q101/1/50.asp > http://support.microsoft.com/support/kb/articles/Q126/7/66.asp I read the first one, and now understand your skew. What you should have really said is that the named pipes will not be stored on the CIFS filesystem and thus the question is irrelevant. The server running the database will create the named pipe as a resource separate from the filesystem storing the database. If the database clients connecting to the server require that the named pipe and the database file reside on the same host (I don't see why the clients should look at the file at all, but some old decripid databases have no concept of server only cooperating clients) then this will not work. However, I venture to say that this is not the case and in theory if you (the original poster) can keep the database file on another NT server you should be able to keep that file on the NetApp as well with no problems. Bear in mind that, as our colleague Mark said, the NetApp is not a database server and will not act as one. You should trreat a NetApp as a very intelligent disk, that is all that it is, a file server. > There are better ones than these, but while I was looking for them Microsoft's > web site went down... If you find them please jot me a note, I'm curious about this stuff. BTW, with NT there is a way to open a named pipe between 2 processes on 2 different boxes, with UNIX it must be on the same system and mount point AFAICT. Tom

1 0

RE: CIFS Administrators vs file ownership
by Muhlestein, Mark 18 Jun '99

18 Jun '99

I just noticed I neglected to 'cc' this to toasters: -----Original Message----- From: Muhlestein, Mark Sent: Friday, June 18, 1999 2:43 PM To: 'Gregory M. Paris' Subject: RE: CIFS Administrators vs file ownership What version are you running? If it's 5.3 or greater you should turn off the wafl.nt_admin_priv_map_to_root option. See http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/index.s… and in particular http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/usermap… l Let me know if that helps or if you have other problems. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Gregory M. Paris [mailto:paris@bose.com] Sent: Friday, June 18, 1999 2:29 PM To: toasters(a)mathworks.com Cc: paris(a)bose.com Subject: CIFS Administrators vs file ownership Toasters, We've recently received our first filer, an F740 with NFS and CIFS. We're in the process of working out all the issues and procedures before we deploy the device. The issue we're struggling with at the moment involves people with NT Administrator access. In the NT world, we admins are used to having accounts with Administrator access (by virtue of being Domain Admins). It never matters to us that our files get created with ownership of "Administrators". In the UNIX world, we're used to using "su" to get root access when we need it. All of our own files are owned by our respective accounts, not root. We intend to merge our UNIX and NT home directories, but life is not smooth for we admins. When we create files on the filer from the NT world, they're owned by Administrator; that's OK. But on the UNIX side, they show up as being owned by root; that's not. We'd like to have our admin access cake and eat it too. In other words, what we'd like is to have our NT Administrator access, but have files get created with our respective ownerships, not root's. How do the rest of you work this issue? Greg -- Gregory M. Paris CIS Engineering Systems Bose Corporation Email: paris(a)bose.com The Mountain Phone: +1 508 766-6080 Framingham, MA 01701-9168 FAX: +1 508 820-0173

1 0

RE: Backup a filer using Omniback
by Muhlestein, Mark 18 Jun '99

18 Jun '99

If OmniBack can backup an NT server via CIFS you can use that method to backup the filer and perserve both UNIX and NT metadata. Mark Muhlestein -----Original Message----- From: Palinckx, Gregory [mailto:gregory.palinckx@netapp.com] Sent: Friday, June 18, 1999 7:45 AM To: Schepers, Jan; 'toasters(a)mathworks.com' Subject: RE: Backup a filer using Omniback Hello Jan, In case you are not aware of it, there is a group within HP over in Germany that is working on the NDMP solution for OmniBack - Last update I received was late last year and they were shooting for a June 99 early release date. You might want to check with HP on the status - Let me know if your HP reps are unaware of the project and I'll see if I can track down a contact and/or the latest release date. To answer your question though, I know you can back up a filer with OmniBack over a NFS mount, but am not sure if it will back up a share or UNC path - if so, I would *suspect* that it will retain ACLs as well as UNIX permissions. Regards, Greg ----------------------------------------------------- Greg Palinckx Phone: 303.770.9158 System Engineer Mobile: 303.882.5996 Network Appliance Email: palinckx(a)netapp.com -----Original Message----- From: Schepers, Jan [mailto:Jan.Schepers@nl.origin-it.com] Sent: Friday, June 18, 1999 2:37 AM To: 'toasters(a)mathworks.com' Subject: Backup a filer using Omniback Hello people, it is very likely that there is somebody who has experience to backup a Netapp filer using HP/Omniback. Questions are: o is it possible ? o Is it possible to backup/restore both CIFS and UNIX meta data like ACL's ? o What about performance ? o What configuration (of the backup client) is required ? TIA, Jan Schepers =============== Origin - Sharing The Power Of Knowledge =============== Jan Schepers Building HCZ 4B.20 Computer Systems & Architectures Vonderweg 11 Origin/Technical Automation 5611 BK Eindhoven mailto:Jan.Schepers@nl.origin-it.com The Netherlands SERI schepers@nlorigin FAX :(+31-40-27)56171 Mobex :(+31-40-27)96025 Phone :(+31-40-27)57503 =======================================================================

1 0

Jump to page:

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