Created attachment 9802 [details] packet capture during the problem We have a freenas server running samba 3.6.12 stack. Not sure if this is fixed in latest 3.6.X or 4.X branches. When we attempt to delete a directory(with more than 500 files) from windows command prompt its failing with "directory not empty" error. X:\>rmdir /S /Q test2 The directory is not empty. In this case, test2 has 600 files in it. On the first attempt of rmdir, it is able to delete only few files. If we run the same command for 2 to 3 times, then all the files getting deleted and finally recursive delete will be succeeded. From packet capture: Client initially send a find request before it start deleting the files in test dir. Before it start attempting to delete the files, client is re-issuing the find request with max output buffer set to 4K. Based on the response, client is attempting to delete the files found in the find response. Again sends find request for next set with 4K buffer. After a while of these iterations, client received STATUS_NO_MORE_FILES for one of the find requests and thats where it stopped deleting the files and attempted to delete the parent dir. Since there are still some files left in the parent dir, delete failed with "STATUS_DIRECTORY_NOT_EMPTY". Deletion from explorer is not having any issue. Able to delete the files in one attempt itself. Because, explorer is not re-issuing the find requests to get the lists in chunk. From the logs, I could figure out that vfs_readdirname() is actually returning NULL after few iterations which is causing the error to be STATUS_NO_MORE_FILES though there are actually few files remaining in the directory. At this point I am not sure why readdir is unable to get/read the remaining entries in the directory.
Did you test against Windows?
(In reply to comment #1) > Did you test against Windows? Yes. I have tested against windows 2K8 server. Its working fine.
Please upload a debug level 10 log also. Thanks, Jeremy.
Created attachment 9807 [details] Client debug level 10 logs. Attached the debug level 10 client logs during the problem.