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]
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.
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:
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.
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
"move-item \\SVM\V\A\F \\SVM\V\A\F2" works as expected (including moved ACLs).
ONTAP Versions is 9.7P6, Windows Client is a Windows Server 2019 (Version 5.1.17763.1852)
Sectrace says in both cases "Access is allowed because inherited ACE grants requested access ..." Disabling ODX did not help. I didnot capture a PKTT -- who would analyze it? Opening a support case will not help me with my task at hand and would cost me me too much time. So I will keep the new folders in the old qtree like "move-item \\SVM\V\A\F to \\SVM\V\A\B\F" with B now a folder under Qtree A.