ndmpcopy defaulting to root volume

[jschaeff]

Hi all,

I've recently started experimenting with the ndmpcopy command to gain a better understanding of it and where I could utilize it in my environment.

I missed the 'Case 3' note in the man pages that states if the destination path specified doesn't already exist on the destination volume, that it'll create that specified destination path under the root volume by default.  As a result, my first couple copies ended up under my root volume on the destination filer.  Fortunately they were small copies with expendable data.  While I don't care about the data in those copies, I would like to keep my root vol as clean as possible.  So my question is, how do i clean this up?

If I browse to \\filer\c$ I see the default etc and home folders.  I also see a new folder called 'vol' which was part of my destination path.  However, I'm unable to access this folder in any way, and I'm not sure how I would go about removing it.

Ideas, thoughts, suggestions??

Thanks,

Justin

[aborzenkov]

Which licenses do you have and what DataONTAP version?

[jschaeff]

I'm using 8.0.2 on both the source and destination filers.  I'm not sure which license you're looking for, but this is what i am licensed for on both the source and destination as well...

a_sis

cf

cf_remote

cifs

disk_sanitization

fcp

flex_clone

flexcache_nfs

http

iscsi

multistore

nearstore_option

nfs

smsql

snapdrive_unix

snapdrive_windows

snapmanager_hyperv

snapmanagerexchange

snapmirror

snaprestore

sv_linux_pri

sv_ontap_pri

sv_ontap_sec

sv_unix_pri

sv_vi_pri

sv_windows_pri

syncmirror_local

[aborzenkov]

If you have both CIFS and NFS you should be able to access root volume and delete files. You say this operation fails, which normally is due to restricted CIFS that comes with FCP/iSCSI licenses.

Do you really have CIFS licensed? If yes, what is security style of root volume (qtree status)?

[jschaeff]

My root volume has the default security settings, and I don’t intentionally use Qtrees.  I can access the default shares on the root volume without any issues.  It’s this “vol” folder that was created as part of the ndmpcopy that I can’t access to remove.

If I map a drive letter to the c$ on the controller I see

R:\>dir
Volume in drive R is C$
Volume Serial Number is 0001-13CD

Directory of R:\

02/27/2012  10:27 AM    <DIR>          etc
08/11/2011  08:06 PM    <DIR>          home
02/25/2012  02:56 PM    <DIR>          .ha
02/24/2012  04:37 PM    <DIR>          vol
               0 File(s)         28,672 bytes
               4 Dir(s)  263,804,723,200 bytes free

The folder/directory that I’m trying to get rid of is “vol”.  “Vol” was created by the NDMP restore because I didn’t realize it was defaulting to the root volume.  When I try to browse into this folder, I get denied.  When I try to view permissions on the folder, both the Share Permissions and NTFS Security tabs are gone for that folder.

The original source path volume was not shared out and had the default UNIX style permissions.  Once I realized the ndmpcopy wasn’t going to the planned destination, I canceled it before it completed.  Does it restore permissions at the beginning of the restore operation, or the end?

[aborzenkov]

When I try to view permissions on the folder, both the Share Permissions and NTFS Security tabs are gone for that folder.

And "qtree status" shows ... ?

[jschaeff]

Qtree status for my root volume shows "unix     enabled     normal".  The same for the source volume.

[jschaeff]

I figured out how to kill it off.

1) Mounted the original source volume that had test data in it, and deleted all data in the source but a single 1k file.
2) I then reran the original command "ndmpcopy /vol/TEST /vol/TEST2".  And let the ndmpcopy command finish.
3) From a Windows 2003 Server Manager MMC, I connected to the c$ on the controller in question.
4) I then launched the Share Wizard and browsed the folder i wanted to share out.  In this case, the folder i wanted to share out the "vol" folder.  I shared it with the default settings. (i'm only sharing so i can delete the contents)
4) I then browsed into the shared "vol" folder and deleted all contents.  (Only the 1k file from step 1 above).  And then closed the UNC session to the "vol" share.
5) I restarted the Server Manager MMC, and stopped sharing of the "vol" share from #4 above.
6) I relaunched the Share Wizard again and browsed to the "vol" folder again.  However, rather than sharing it, I right clicked on the folder, and selected Delete from the context menu.  Voila, gone.  Then cancled my way back out of the share wizard.

It's not elegant, but it is gone, and space that unintentional copy consumed on my root volume has been reclaimed.