- ONTAP 9
- MacOS 10.14
- MacOS 10.15
From SMBv2 onwards, when a file or folder is deleted a so called "delete on close" is set on the folder.
When the folder is closed subsequently, it will be deleted from the file system.
A MacOS CIFS client behaves different from a Windows client in the way it requires exclusive access to a folder when opening for deletion.This behavior can causes a sharing violation preventing the client from deleting the folder.
example from packet trace:
18557 2020-01-30 15:46:09.003908 172.18.24.33 172.18.20.90 SMB2 Create Request File: ...\Folder1\TestFolder
18558 2020-01-30 15:46:09.004297 172.18.20.90 172.18.24.33 SMB2 Create Response File: ...\Folder1\TestFolder
44599 2020-01-30 15:46:24.759237 172.18.24.49 172.18.20.90 SMB2 Create Request File: ...\Folder1\TestFolder;SetInfo Request FILE_INFO/SMB2_FILE_DISPOSITION_INFO;Close Request
44600 2020-01-30 15:46:24.759696 172.18.20.90 172.18.24.49 SMB2 Create Response, Error: STATUS_SHARING_VIOLATION;SetInfo Response, Error: STATUS_SHARING_VIOLATION;Close Response, Error: STATUS_SHARING_VIOLATION
- frame 18557: client A opens the file for READ access, sharing for READ,WRITE,DELETE. (The file is never closed within this packet trace.)
- frame 44599: client B opens the file for DELETE access, sharing none (exclusive access to the file)
- frame 44600: client B receives a STATUS_SHARING_VIOLATION
A possible workaround would be to:
- Create a "to-be-deleted" folder on the same share
- Move the empty directory into "to-be-deleted" and give it a unique name (e.g. based on the hostname and date of the client)
- Attempt to delete the empty directory
- If the deletion works, all is fine
- If the deletion fails, you can clean up later
Note: The unique name in step 2 ensures that future renames on the same directory name would be successful.