toasters

toasters@lists.teaparty.net

13520 discussions

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

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