GNOME Bugzilla – Bug 792147
non-empty directory will not delete
Last modified: 2018-07-09 13:35:05 UTC
Summary: Deleting a directory containing 1+ files doesn't succeed. Nautilus shows the directory as deleted, but upon refresh it reappears (it was never deleted). There are no errors server or client side. When trying to delete the same directory with same share login from macOS 10.13 or Windows 10, the delete succeeds as expected. Configuration: Fedora 27 Server, samba-4.7.3-3.fc27.x86_64 Fedora 27 Workstation, samba-client-4.7.4-0.fc27.x86_64 Fedora 26 Workstation, samba-client-4.6.5-0.fc26.x86_64 Reproduce steps: 1. Nautilus, navigate to target dir to delete. 2. Select target dir. 3. Press delete key. Confirm dialog asking if I want to permanently delete the target dir. Click on red delete button. Results: The target directory vanishes in Nautilus, this is expected. However, via ssh "ls -l" on the server directory containing the target, it is not deleted. And if in Nautilus I navigate outside the containing directory (click on Home for example) and then navigate back to the directory containing the target directory, the previously deleted directory is visible, i.e. it was not deleted. Expected: I expect the target dir to actually be deleted. This works fine with other clients, but not Fedora 26 or Fedora 27 clients (that's as far back as I've tested). Additional info: a. There are no hidden files in the target directory. b. The parent directory, target directory, and all the files in the target directory have 777 permissions, and samba_share_t:s0 selinux label. c. If the files inside the target dir are deleted with Nautilus, they really do delete; and then if the now empty target dir is deleted with Nautilus, it too really does delete. Nautilus is refusing to delete non-empty directories, for unknown reasons.
Created attachment 366229 [details] client smb.conf
Created attachment 366230 [details] server smb.conf
Created attachment 366232 [details] gvfsd.log When I click on the 'test' directory, then press the delete key and confirm the permanently delete dialog, I get the following lines: smbc_stat(smb://f27s.local/scratch/test3) SMBC_getatr: sending qpathinfo smbc_stat(smb://f27s.local/scratch/test3) SMBC_getatr: sending qpathinfo parsed path: fname='smb://f27s.local/scratch/test3' server='f27s.local' share='scratch' path='\test3' options='' SMBC_check_options(): server='f27s.local' share='scratch' path='\test3' options='' smbc_stat(smb://f27s.local/scratch/test3/test4.txt) SMBC_getatr: sending qpathinfo smbc_stat(smb://f27s.local/scratch/test3/test3.txt) SMBC_getatr: sending qpathinfo smbc_stat(smb://f27s.local/scratch/test3/test2.txt) SMBC_getatr: sending qpathinfo smbc_stat(smb://f27s.local/scratch/test3/test1.txt) SMBC_getatr: sending qpathinfo smbc_stat(smb://f27s.local/scratch/test3) SMBC_getatr: sending qpathinfo smbc_rmdir(smb://f27s.local/scratch/test3) And then what comes after that, is click on Home in Nautilus, and then back to the share which refreshes it and it shows 'test' was not deleted.
Comment 3 attachement was obtained with: $ pkill gvfs $ GVFS_SMB_DEBUG=10 $(find /usr/lib* -name gvfsd 2>/dev/null) --replace 2>&1 | tee gvfsd.log
I get the same results as Nautilus with this, I'm not certain if it's expected. In this example test3 contains four plain text files: test1.txt, test2.txt, etc. same as the one I tried to delete above. test4 directory is empty. The one with files is not deleted with the rmdir command, the one without files is deleted. Does this mean it's an libsmbclient bug? Or is the behavior somehow expected, and Nautilus is supposed to do its own recursive delete of every file before rmdir? [chris@f27h ~]$ smbclient //f27s.local/scratch -U chris Enter SAMBA\chris's password: Try "help" to get a list of possible commands. smb: \> ls . D 0 Tue Jan 2 20:37:07 2018 .. D 0 Wed Aug 2 17:32:09 2017 endless OS D 0 Tue Jan 2 13:28:09 2018 androidstuff D 0 Sun Nov 12 15:57:45 2017 gits D 0 Sun Dec 10 00:24:09 2017 broadcom-wl-6.30.163.46.wl_apsta.o N 21367723 Mon Jul 29 09:27:41 2013 moms couch D 0 Thu Dec 21 13:27:36 2017 test3 D 0 Tue Jan 2 16:41:48 2018 test4 D 0 Tue Jan 2 16:41:48 2018 1073739776 blocks of size 1024. 503896204 blocks available smb: \> rmdir test3 smb: \> ls . D 0 Tue Jan 2 20:37:07 2018 .. D 0 Wed Aug 2 17:32:09 2017 endless OS D 0 Tue Jan 2 13:28:09 2018 androidstuff D 0 Sun Nov 12 15:57:45 2017 gits D 0 Sun Dec 10 00:24:09 2017 broadcom-wl-6.30.163.46.wl_apsta.o N 21367723 Mon Jul 29 09:27:41 2013 moms couch D 0 Thu Dec 21 13:27:36 2017 test3 D 0 Tue Jan 2 16:41:48 2018 test4 D 0 Tue Jan 2 16:41:48 2018 1073739776 blocks of size 1024. 503896204 blocks available smb: \> rmdir test4 smb: \> ls . D 0 Tue Jan 2 21:23:53 2018 .. D 0 Wed Aug 2 17:32:09 2017 endless OS D 0 Tue Jan 2 13:28:09 2018 androidstuff D 0 Sun Nov 12 15:57:45 2017 gits D 0 Sun Dec 10 00:24:09 2017 broadcom-wl-6.30.163.46.wl_apsta.o N 21367723 Mon Jul 29 09:27:41 2013 moms couch D 0 Thu Dec 21 13:27:36 2017 test3 D 0 Tue Jan 2 16:41:48 2018 1073739776 blocks of size 1024. 503896204 blocks available smb: \>
Thanks for your report. Nautilus should recursively delete all those files in case of G_IO_ERROR_NOT_EMPTY error, but maybe gvfsd-smb returns something wrong in this case. Can you please obtain the log again also with GVFS_DEBUG=1 to see what is returned to the client? I would say that the smbclient behavior is expected.
Created attachment 366264 [details] gvfsd log 2 This includes GVFS_DEBUG=1. I inserted three two line breaks in the log: 1. right before clicking on the target directory (test1) then deleting it. 2. right after that deletion supposedly completes. I then walked away from Nautilus for a while and it records a bunch of lines. trash: Queued new job 0x55ff0aaf6250 (GVfsJobEnumerate) 3. upon return, I clicked in Nautilus away from the share, then back to the share, to confirm the deleted directory was not deleted.
Created attachment 366266 [details] samba server log This is the log for the connection to the client, with smb.conf log level = 10. So it's excessively verbose and I can't parse the actual failure to delete, even though it seems to be going through the motions of doing it. Smells like it's a permissions problem and yet I can't find evidence of it, and then of course other clients can delete the dir OK.
Thanks, I can also reproduce the issue... smb-share: Queued new job 0x55e2c6015a50 (GVfsJobDelete) smbc_stat(smb://f27s.local/scratch/noperms/test1) SMBC_getatr: sending qpathinfo smbc_rmdir(smb://f27s.local/scratch/noperms/test1) smb-share: send_reply(0x55e2c6015a50), failed=0 () smbc_rmdir returned 0, but should return non-zero status instead. There is evidence that the dir is not empty, but I do not see anything else relevant in the server log: [2018/01/03 15:42:07.847704, 10, pid=9665, effective(1000, 1000), real(1000, 0)] ../source3/smbd/dir.c:2156(can_delete_directory_fsp) got name test1.txt - can't delete Actually, the smbclient behavior is also wrong. An error message should be printed in case of error, but it is not for non-empty dir: smb: \> rmdir NONEXISTINGDIR NT_STATUS_OBJECT_NAME_NOT_FOUND removing remote directory file \NONEXISTINGDIR smb: \> rmdir NONEMPTYDIR smb: \> See source: https://git.samba.org/?p=samba.git;a=blob;f=source4/client/client.c#l2268 Can you please file a new bug report on SAMBA tracker and add a comment including the link, please? https://bugzilla.samba.org/
I started this thread for starters: https://lists.samba.org/archive/samba/2018-January/213048.html
I agree that no error for rmdir NONEMPTYDIR is a bug, if that command will not delete an empty directory. But I don't understand why Nautilus' inability to delete this directory is NOTGNOME; are you asserting this is a Samba bug between client and server? Because as mentioned, macOS and Windows 10 delete the directory. Also, since smbc_rmdir returned 0, that means the directory was not deleted, but Nautilus show it has deleted it (bogus, once refreshed Nautilus shows it's not deleted). That behavior does seem to be a legitimate Nautilus bug but maybe that needs to be filed separately for Nautilus? Seems Nautilus is vanishing the directory without confirming the command succeeded.
This is not GNOME bug, because Nautilus relies on GVfs and GVfs relies on libsmbclient. The smbc_rmdir return value indicates that there is no error, i.e. the dir was successfully removed. As far as I can tell almost all the libsmbclient functions return 0 on success and I am pretty convinced that also smbc_rmdir. So GVfs tell that to Nautilus. It will work correctly if smbc_rmdir return ENOTEMTPY. We can't double check everything, people still complaining about performance.
Thanks for the post to the samba list...
It looks like rmdir is not expected to work on anything other than an empty directory, whereas deltree does a recursive delete of contents then removes the directory. Using deltree in my case does succeed. I don't know if gvfs-smb should be using deltree instead of rmdir for this use case. There seems to be no downside to using deltree for both empty and non-empty directories.
https://bugzilla.samba.org/show_bug.cgi?id=13204
As far as I can tell, libsmbclient.h API doesn't provide deltree, but anyway it is not what we want, our API expects failure on non-empty directory...
As an extra data point, Dolphin correctly handles this situation and properly deletes non-empty directories.
I have been about to add workaround for it, but it works correctly for me with samba-4.8.0-0.5.rc4.fc28.x86_64 currently, so is this still an issue?
I can confirm that this IS still an issue with Fedora 28, and these packages: samba-libs-4.8.1-0.fc28.x86_64 samba-dc-libs-4.8.1-0.fc28.x86_64 samba-common-4.8.1-0.fc28.noarch samba-client-libs-4.8.1-0.fc28.x86_64 samba-common-tools-4.8.1-0.fc28.x86_64 samba-4.8.1-0.fc28.x86_64 samba-client-4.8.1-0.fc28.x86_64 samba-common-libs-4.8.1-0.fc28.x86_64 So, no, this is not fixed.
how is this "resolved" ? - I have this problem in Ubuntu 18.04 too..
It is resolved as NOTGNOME, which means that the bug is not on our side, but in libsmbclient library in this case, see bug from Comment 15. So, please ping samba people, not me... But yes, you are right, I am still able to resolve this issue, not sure what I did wrong last time. So, given the fact that this is pretty important and samba bug is still without response, let's introduce workaround here...
Created attachment 371928 [details] [review] smb: Add workaround to fix removal of non-empty dir smbc_rmdir returns 0 for non-empty dir currently even if the dir has not been removed. Add workaround and return G_IO_ERROR_NOT_EMPTY in this case. Can somebody of you test the patch?
Thank you for fixing this. I would test, if I knew how to get proper sources, compile this file (only), then clean up so I don't keep on updating hundreds om MB of sources, and/or not getting standard updates because I have an private build om something. - on the other hand, if you have a AMD binary for ubuntu 18.04 - I could easily test that.
You can find some info there, but it isn't so easy: https://wiki.gnome.org/Projects/gvfs/debugging Nevermind, let's go with this...
Pushed to master as commit 4967b7a2 and gnome-3-28 as commit 42f65062.
This is still a bug in Fedora 28 Workstation. gnome-shell-3.28.2-1.fc28.x86_64 gvfs-smb-1.36.2-1.fc28.x86_64 samba-client-4.8.3-1.fc28.x86_64
Right, I am going to backport the patches in Fedora... it will be part of gvfs-smb-1.36.2-2 (or you can alternatively update to gvfs-1.37.2-1 from rawhide).