Hide Forgot
Description of problem: Nautilus fails to delete non-empty directories on Samba shares. Selecting a directory and right clicking and selecting delete permanently results in the directory disappearing from the Nautilus window, as would be expected for a delete. However, looking on the server, the directory is stil pressent. Navigating out of the directory and back into it in Nautilus shows that the directory re-appears. Debugging gvfs shows that no errors arise due to this. Version-Release number of selected component (if applicable): nautilus-3.26.3.1-1.fc27.x86_64 gvfs-smb-1.34.2.1-1.fc27.x86_64 gvfs-1.34.2.1-1.fc27.x86_64 How reproducible: Everytime Steps to Reproduce: 1. Access a Samba share in Nautilus 2. Select a non-empty directory, right click, and choose to delete permanently 3. Actual results: Directory not deleted Expected results: Directory deleted.
Mailing list discussion: https://lists.samba.org/archive/samba/2018-January/213048.html Samba bug report: https://bugzilla.samba.org/show_bug.cgi?id=13204 Gnome bug report: https://bugzilla.gnome.org/show_bug.cgi?id=792147
Verified this behaviour persists in Fedora 28 beta.
Proposed as a Blocker for 28-final by Fedora user jgu using the blocker tracking app because: The Fedora 28 release criteria state: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." I would argue that deleting directories correctly on Samba shares is basic functionality of the default file manager (Nautilus). The reason that it can't is due to a bug in libsmbclient provided by the Samba package. From an end user perspective, Nautilus appears to have deleted a directory, but actually hasn't.
Discussed during the 2018-04-09 blocker review meeting: [1] The decision to classify this bug as a RejectedBlocker was made as the QA team does not find the "basic functionality" of the Nautilus package to be impacted, as there are several obvious workarounds and this could be addressed with an update in the future. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-04-09/f28-blocker-review.2018-04-09-16.01.txt
Note that this text in the F28 Common Bugs is incorrect: "If you access Samba (smb) shares using Nautilus, it's not possible to delete non-empty directories due to a bug. Current workaround is to delete files in that directory first (tedious), or use a different application for accessing that share (that is not using gvfs library, as Nautilus does)." It's not a case of using an application that doesn't use gvfs. Rather, it's a case of using an application that doesn't make use of libsmbclient. I don't know of any such application, though.
(In reply to Jonathan Underwood from comment #5) > Note that this text in the F28 Common Bugs is incorrect: > > "If you access Samba (smb) shares using Nautilus, it's not possible to > delete non-empty directories due to a bug. Current workaround is to delete > files in that directory first (tedious), or use a different application for > accessing that share (that is not using gvfs library, as Nautilus does)." > > It's not a case of using an application that doesn't use gvfs. Rather, it's > a case of using an application that doesn't make use of libsmbclient. I > don't know of any such application, though. I have confirmed that using Dolphin is a workaround for this problem.
Proposing as a PrioritizedBug. This is a very common use case and a very annoying issue for anyone using samba shares.
There's a candidate patch here: https://bug792147.bugzilla-attachments.gnome.org/attachment.cgi?id=371928 Any chance of pushing a package build with this to updates-testing ?
Guenther, will it be possible please to provide a fixed package for the F28 release into updates-testing (see the comment above) ?
Accepted as a PrioritizedBug
This bug has been resolved with a Samba update that has been shipped to f28 recently. Just verified it with nautilus and libsmbclient-4.8.5-0.fc28.x86_64