Rene:

I have seen this behavior and have been simarly frustrated when migrating CIFS volumes from Traditional to Flexvols.

In my opinion, Netapp should NOT be renaming CIFS shares when you change volume names. They do this automatically without warning you or logging.

I know they're doing it because they think they're being helpful; but really the only time I can forsee changing volume names is if you're doing a migration like you're doing. VERY frustrating indeed.

I found myself having to document all the existing shares, and write a script that deletes, then re-creates all the shares and their permissions on the new volume. Hours of work.

Netapp, is there a way to disable this "feature" prior to renaming a volume?

Glenn (the other one)

________________________________

From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of René Bormann Sent: Thursday, February 08, 2007 12:41 PM To: toasters@mathworks.com Cc: René Bormann; Fox, Adam Subject: Re: moving data from trad -> flex vols

Hello Toasters,

well, the root vol now moved to the new DS14 flex-vol.

But this night I tried to move the data (shares / lun's / exports) from the old /vol/vol0 (trad) via "ndmpcopy -l 0 /vol/vol0 /vol/vol1" and some hour later, "ndmpcopy -l 0 /vol/vol0 /vol/vol1".

Everthing was copied. All Clients where offline, and than I renamed /vol/vol0 -> /vol/vol0old and /vol/vol1 /vol/vol0. Because I thought than after the reboot all shares and luns and nfs-exports are back on /vol/vol0 but now on the new DS14.

Well I failed, I found out that the vol rename also renamed the CIFS Shares Paths and also the LUN paths. So the CIFS clients where still reading from the old FC9 (/vol/vol0old now) and the iSCSI clients where too. Because I did't terminate CIFS and NFS and iSCSI. To be honest, cool renaming feature to prevent stupid germans from losing data ;-)

So, I though be smart forget about the LUNs, they are fine, care about the shares. "CIFS terminate" and replace vol0old -> vol0 in the /etc/cifsconfig_share.cfg. "CIFS restart". "Year! I am the master !" But I was too stupid again. Because now my CIFS Clients got the shares but they could not see any data. And I got no idea why!

So I "vol rename vol0 vol1" and "vol rename vol0old vol0"

And now the CIFS clients connect back to their shares on the old FC9 again.

So whats wrong about my proceedings? And the second question to save time, how to I move the iSCSI LUNs to the new volume?

Thanks,

Rene

René Bormann wrote:

Thanks to all how answered! Just used my sleepless night here in germany to fix it. Took me half an hour! - René Fox, Adam wrote:

If you are using SecureAdmin/Secure FilerView/SSL, you need to restart the secureadmin services when you cross the 7.x line. There was a major code change starting in 7.0 and the service must be manually restarted (a reboot won't do it). Start here for docs: http://now.netapp.com/NOW/knowledge/docs/ontap/rel721/html/ontap/upgrade/con... -- Adam Fox adamfox@netapp.com -----Original Message----- From: René Bormann [mailto:bormann@bbtel.de] Sent: Tuesday, February 06, 2007 5:14 PM To: toasters@mathworks.com Subject: moving data from trad -> flex vols Hello, we are running an FAS920 with FC9 shelfs with data and new empty DS14 shelfs. On the FC9 we got one volume /vol/vol0 with root and data on it. Last week we upgraded from ONTAP 6.5.6 to 7.2.1 without problems. Now we want to move our data to the DS14 shelfs. We created one aggr1 with lots of drives. After that we created two new flex vols - /vol/root (20GB) and an /vol/vol1 (1TB) for the data. We copied the root data with no clients on the filer with "ndmpcopy -l0 /vol/vol0/etc /vol/root/etc". Worked fine in 7 minutes. Than we change the booting volume with "vol options /vol/root root". Booting from it, no problem -but now by requsting http://filer-ip/na_admin just the first page came and we were not able to start the FilerView Web-App. So so we switch the root vol again with "vol options /vol/vol0 root" and FilerView works fine. In the message file we found that one: Sat Feb 3 09:16:09 CET [httpd.socket.listener.create:error]: HTTPS Initialization failure; could not create listener socket. Nothing else. Can anybody help? Thanks, René -- ----------------------------------------- Telefonkonferenzen zum Festnetzpreis! Einfach kostenlos Konferenzraum anfordern http://www.talkyoo.net ----------------------------------------- René Bormann Geschäftsführer BB Tel GmbH Jungfernstieg 30, 20354 Hamburg Register: Amtsgericht Hamburg, HRB 86074 Geschäftführer: René Bormann Tel: +49 (0) 1805 - 65 777 777 * Fax: +49 (0) 1805 - 65 777 799 * http://www.bbtel.de ----------------------------------------- * (bbtel.de 14ct/min) ** (es entstehen die Kosten, die ihre Telefongesellschaft zu einer Hamburger Festnetz-Rufnummer berechnet.) -----------------------------------------

I've been trying to get NFSv3 home directory mounts with sec=krb5 working between a Netapp filer running OnTap 7.0.5 and a Fedora Core 6 client with the latest nfs-* RPMs installed and kernel version 2.6.18-1.2869.fc6. Our KDCs run FreeBSD 6.1 with the MIT Kerberos port installed. Authentication seems to work okay,

Script started on Thu Feb 8 15:31:23 2007 bsod$ /bin/su - testacct Password:

but the home directory isn't usable.

/bin/su: warning: cannot change directory to /home/testacct: Permission denied -bash: /home/testacct/.bash_profile: Permission denied

The mount though did succeed:

-bash-3.1$ mount | grep testacct sinagua:/vol/vol0/home/testacct on /home/testacct type nfs (rw,nfsvers=3,tcp,timeo=600,rsize=32768,wsize=32768,hard,intr,sec=krb5,addr=172.16.1.252) -bash-3.1$ grep testacct /etc/auto.home testacct -rw,bg,vers=3,tcp,timeo=600,rsize=32768,wsize=32768,hard,intr,sec=krb5 sinagua:/vol/vol0/home/testacct

But

-bash-3.1$ klist -e klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_500_vZWPDb)

Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached

Okay, I thought the PAM stack would provide the credentials. But even after running kinit...

-bash-3.1$ kinit Password for testacct@CS.ARIZONA.EDU: -bash-3.1$ cd -bash: cd: /home/testacct: Permission denied -bash-3.1$ klist -e Ticket cache: FILE:/tmp/krb5cc_500_vZWPDb Default principal: testacct@CS.ARIZONA.EDU

Valid starting Expires Service principal 02/08/07 15:32:03 02/09/07 15:32:03 krbtgt/CS.ARIZONA.EDU@CS.ARIZONA.EDU renew until 02/08/07 15:32:03, Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1

Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached -bash-3.1$ exit logout

...the directory isn't usable

-bash: /home/testacct/.bash_logout: Permission denied bsod$ exit exit

Script done on Thu Feb 8 15:32:39 2007

Running rpc.gssd in verbose mode produced

Script started on Thu Feb 8 15:30:29 2007 bsod$ /sbin/lsmod | grep sunrpc sunrpc 158333 6 nfs,lockd,nfs_acl,rpcsec_gss_krb5,auth_rpcgss bsod$ mount | grep rpc_pipe sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) bsod$ sudo strace -o /tmp/rpc.gssd -f /usr/sbin/rpc.gssd -f -vvv Using keytab file '/etc/krb5.keytab' Processing keytab entry for principal 'nfs/bsod.cs.arizona.edu@CS.ARIZONA.EDU' We will use this entry (nfs/bsod.cs.arizona.edu@CS.ARIZONA.EDU) Using (machine) credentials cache: 'MEMORY:/tmp/krb5cc_machine_CS.ARIZONA.EDU'

That's the extent of output while the commands above ran.

And the (enormous) strace output file seems mostly to consist of polling loops something like

2720 poll([{fd=6, events=POLLIN, revents=POLLERR|POLLHUP}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}], 32, 500) = 1 2720 chdir("/var/lib/nfs/rpc_pipefs/nfs") = 0 2720 open("/var/lib/nfs/rpc_pipefs/nfs", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7 2720 fstat64(7, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 2720 fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 2720 getdents64(7, /* 3 entries */, 4096) = 80 2720 getdents64(7, /* 0 entries */, 4096) = 0 2720 close(7) = 0

Any ideas?