Why MacOS clients may fail to delete an empty folder ?

Applies to

• ONTAP 9
• CIFS
• MacOS 10.14
• MacOS 10.15

Answer

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

Additional Information

A possible workaround would be to:

1. Create a "to-be-deleted" folder on the same share
2. 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)
3. 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.