Certain paths on SMB share on 20285, 20282 return server cannot perform the requested operation

Iron Contributor

I upgraded a fully functional 2019 backup file server a week ago to 20282, and although everything seemed fine, a nightly backup script (using robocopy) started to fail reading on seemingly random paths.  After more investigation, I found that certain paths are now inaccessible via SMB and produce the following error message in File Explorer when you try access them:

 

\\server\backup\path\to\folder is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.

The specified server cannot perform the requested operation.

 

The share goes to a volume that is two drives in a storage pool, ReFS, with de-duplication.  The folders and files are fully accessible locally, it is only over SMB that this error is returned.

 

Further thoughts:

  • This doesn't appear to do with permissions, this was an upgrade (at first) and all permissions are inherited.  The share is for the entire disk and only certain paths at affected.
  • I clean installed 20285, same problem.
  • I clean installed 2019, it will no longer mount the virtual disk, it claims it's RAW, upgrading again to 20285 fixed that.  (Why?)
  • I am able to "fix" individual folders having this problem, by moving the folder to boot drive, and then back to the data storage pool disk.  Then the SMB path works for that folder.
  • So far, it seems to be only folders that are affected.
  • Trying from code, WinAPIs MoveFileEx or FindNextFile return error 58.
  • Trying to access the share from the server also produces the error, as well as the two Windows 10 clients I tried.
  • I disabled SMB2/3 and installed SMB1 to test.  Same problem on SMB1.
  • The problem does not appear if I RDP from the server to another machine, and access the files over the \\tsclient share.
  • I setup an SSH server and I'm able to access the inaccessible folders over SSH/SCP without any issue.
  • These are standard ascii paths, no non-English characters.
  • Length of the path doesn't appear to be an issue, as far longer paths work fine.
  • However, Wireshark shows a "[Malformed Packet: SMB2: length of contained item exceeds length of containing item]" returned as part of Explorer's file access.

 

1 Reply

@Jonathan Kay thanks for reporting this. Can you email me directly at nedpyle@microsoft.com, I need to have you collect some data while reproducing this under one of our logging tools.