Powershell Move-Item (or cmd.exe / move) into a qtree gives access denied

[DidierW]

Hi,

When I try to move a directory into a qtree on the same volume, it results in an access denied.

Moving the directory with explorer.exe does work but any use of a shell (for an automation script) fails:

I have "full control" on the volume and as I mentionned moving with explorer.exe does work ....

I also tried different (non-administrative) shares ... something is wrong here.

Any clues ?

Is this a known bug?

Thank you!

Regards,

Didier

[Ontapforrum]

Hi,

I tried your steps and made some observations.

Move-item: works  perfectly on file without any issues. However, when it comes to folder [using UNC path], it kept giving access denied error as you made an obervation. I then tried copy-item cmd, it workws perfectly (with in the same volume and different) however it keeps the original folder intact, which is not your desrire.

Then I tried to give a name for the destination folder in command-line for move-item and that worked.

Move-item: works on folder [provided you mention the name in destination path in command-line, it need not exist prior]

PS C:\Users\Administrator> Move-Item -Path \\192.168.0.210\c$\vol_CIFS\folder-2-copy -Destination \\192.168.0.210\c$\vol_CIFS\folder-2-copy-new -Force

I see two options here:
1) Either use copy-item

or,
2) Give a another temp name to folder to be moved in the destination and then re-name it back to original ---- This looks practical.

Example:

source = -Path \\192.168.0.210\c$\vol_CIFS\folder-2-copy
Destination \\192.168.0.210\c$\vol_CIFS\folder-2-copy-new
once  moved, rename it back to -folder-2-copy

[DidierW]

Thank you for your help!

The problem is that I need to move it inside a "Qtree" nowhere else. It needs to be the "Archives" Qtree Directory.

I mapped a drive or did many tests ... it always results in an "access denied" . I you use a "standard" Archives Directory (via mkdir Archives) it works perfectly ... it really seems the "Qtree" is the problem.

[Ontapforrum]

I tried moving from qtree to qtree in the same vol, and it works.

Example:

PS C:\Users\Administrator> move-Item -Path \\192.168.0.210\c$\vol_CIFS\qtree_cifs\cool -Destination \\192.168.0.210\c$\vol_CIFS\qtree_cifs\cool2 -Force

[DidierW]

Hello,

Your scenario indeed works for me too.

move-item \\SVM\DIVERS\QTREE1\TestDir \\SVM\DIRVERS\QTREE1\TestDir2

But this doesn't work:

(moving Testdir inside  Qtree1)

move-item \\SVM\DIVERS\TestDir \\SVM\DIRVERS\QTREE1

"access denied"

So it is not possible to move a directory (outside of a qtree) inside an existing qtree with command line (cmd or powershell). I can only move it inside with explorer.exe (with the GUI it does work!!!).

Would you mind giving it a try please?

Here is a person (last post in discussion) describing the same problem:

https://community.netapp.com/t5/Data-ONTAP-Discussions/Converting-regular-folders-to-Qtrees/td-p/137720

Regards,

Didier

[Ontapforrum]

Hi,

Yes, I did try that yesterday, but it looks like 'dir' move does not like to be outsode it's home boundary. I.e if it's inside the same vol or qtree, it works. However, moving it outside it's home boundary, it fails. 

One thing that we need to be observant of  is that : - We are using Microsoft Powershell comamnd 'Move-Item' and it's not something that is integrated with NetApp SDK (Zapi). Most of the tasks that works are the ones we carry out via 'ontap ps modules', where as in this case we are using outside of this integration. 

Hence, there is bound to be a limitation I believe. I am sure NetApp poweshell Module developer/Integrator will have more understanding on this.

The Move-Item command we are using is purely based on this Microsoft official doc, outside of Ontap Powershell:
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/move-item?view=powershell-6

[GidonMarcus]

Hi all

I’m afraid I don't have a lab available to do the tests myself, but I want to raise a few points in order to get the correct framing.

1. The right tool in ONTAP to follow any “access denied” is the sectrace tool, I think it should be used first to understand if it’s a true access issue that ONTAP is also aware of - or not:

https://kb.netapp.com/app/answers/answer_view/a_id/1071847/loc/en_US
at that point – please also provide the ONTAP version (the “version” command should work), and look for any events in the system log during the time of the move-item (event show command).

2. If sectrace not giving us much. I think it will be good to keep it recording, and also get a packet trace at the same time to see what the client is asking the storage to do, as in general the client and PS command doesn’t know the difference from qtree to volume (see exception below). The packet trace can be collected from the NetApp (search pktt) or from the client using tools like Wireshark or “netsh trace”. I think its worth also to take traces to compare a normal windows cut-paste (assuming that cut-paste working as expected), and move scenarios that you descried that do work for you.

3. One exception we might see in the packet trace is ODX (copy offload). I don’t think ODX should be utilized within the same volume (it should just use the built-in and old school smb-move command). The problem with ODX is that there’s dozens of cases where it’s not supported/working – so if it does get utilized - we might hit one of these cases.

 If we get a packet trace we can look for the ODX commands with the following filters:
smb2.cmd == 11   <<<<gives you all the FSCTL….look for OFFLOAD

smb2.ioctl.function == 0x00094264      <<<gives you FSCTL_OFFLOAD_READ

smb2.ioctl.function == 0x00098268      <<<gives you FSCTL_OFFLOAD_WRITE

(Taken from this kb: https://kb.netapp.com/app/answers/answer_view/a_id/1006170)

If we do see ODX being involved. I think it’s worth trying to disable it, reboot the windows client, and see what’s happens.

vserver cifs options show -vserver vserver_name -fields copy-offload-enabled

vserver cifs options modify -vserver vserver_name -copy-offload-enabled false

4. If you get to a dead-end, We need as much information documented so whoever try to reproduce it compare apples to apples - from windows I think we need the following output from PowerShell :

Get-Command Move-Item|ft Version
get-host|ft Version
gwmi Win32_OperatingSystem|ft Caption,version
Get-HotFix|ft HotFixID          
fltmc instances
Get-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode" | ft F*

Gidi