Manjaro is the only distro that I have used extensively, so I don’t know if this is a Manjaro thing or it’s common for Linux in general. I could be reading/writing to a file in Kate… then close Kate and then try to “Safely remove” via Disks & Devices, and it won’t. Upon inspection, it’s always “file.so” that is holding the drive hostage. Is this a bug? Anyone else experiencing this?
The file you are reading/editing is on some external drive.
You are reading/editing it.
Then you are done.
And want to unmount the drive?
How did you open that file?
Through the file manager?
(which is probably still open and accessing/referencing that file)
You need to give
and review
your process
how you opened that file (in Kate)
which is residing on some external medium.
in that case,
closing Kate is not enough - the file manager,
from which you called Kate to open the document,
also is still accessing it.
… probably
We don’t know what you did.
The description is too vague.
By default, the drive is not mounted, but by clicking on its icon in the Dolphin file manager sidebar it auto mount and then I double click on a text file to open it in Kate. Do some editing, and then exit Kate. Even close down Dolphin. With nothing open, I do a “Safely remove” via Disks & Devices at the bottom-right of the taskbar. It won’t unmount because file.so is using it. Here’s the error Dolphin spells out when trying to “Safely Remove” via Right click on the Dolphin sidebar:
One or more files on this device are opened in application "dolphinEiaBLH.5.slave-socket".
… this, for me, points to Dolphin still having it open and thus not being able to unmount it
But I don’t have or use KDE - so I cannot really speak from experience.
Someone else probably can.
Cheers!
Could KDE/Baloo be indexing the drive. Maybe disable indexing and test (KDE System Settings > Search). If it works and you want indexing, update the config.
I know you said nothing is open — dolphin (pgrep -c dolphin should be 0), kate, and konsole (or at least make sure you aren’t in the directory).
The file.so that you are referring to I believe is /usr/lib/qt/plugins/kf5/kio/file.so and is part of the kio package, KDE Input/Output. There are all kinds of protocols, file is one, ftp, http, trash are some others. It’s an abstraction layer so an application can access data of a certain type on any device without having to know the details.
What you need to realize is that file I/O is an asynchronous process. Just because you’ve closed the editor doesn’t mean that the modifications you made to the file are synchronized to the actual file on the drive itself. This is done in the background ─ remember that you’re using a multitasking OS ─ and it could take some time.
If you really need or want to unmount the drive ─ e.g. because it’s an external drive and you want to disconnect it ─ then best is to log out of your Plasma session completely and wait a few seconds. This will close all of your open files. You can then log in and unmount the drive, if it wasn’t unmounted already by the logout.
I tried the log out thing and it actually cleared up everything, but this would be a very strange way to unmount a drive. 
Here’s the thing: This USB flash drive is only 32GB and there’s not much stuff in it. I unchecked “Also index file content” (KDE System Settings > Search) just in case.
Here’s the situation. Let’s say I just turned on my computer. Typed in my password and then logged into the system. Opened up Dolphin, clicked on the drive icon via Dolphin sidebar to mount it, and then clicked on a text file (markdown to be exact) in this drive, to open it with Kate. Then right away, I closed Kate and Dolphin. So I’m left with absolutely nothing running. Then opened up Yakuake, did a pgrep -c dolphin and it returned 0.
lsof | grep /run/media/******/Transfer gives this result:
file.so 3754 ****** 5r REG 8,18 9486 268 /run/media/******/Transfer/Linux Todo.md
and if I try to do a “Safely Remove” in Dolphin, I get this error:
One or more files on this device are opened in application "dolphinoxWTUC.6.slave-socket".
NOTE: I already made Timeshift backup, so I’ll restore everything to its original state later and test it out to see if this problem still happen with a clean install. I’ll update later.
Ah, there we have it ─ you hadn’t mentioned that it was a USB flash drive. The throughput on the USB bus ─ and especially the I/O on a USB flash drive ─ is by far not the same as for an internally mounted SSD or HDD. So you think you’re done when you’re closing the editor or when you’re closing Dolphin, but in reality your system is still buffering data and writing to the flash drive.
Logging out is just a dirty shortcut to getting everything in your session to forcibly close when nothing else works.
… there is also the
sync
command
From
man sync
sync - Synchronize cached writes to persistent storage
When that has finished you should be able to unmount.
Same issue here, I use a iSCSI disk… Mount it, play video from it, when done I try to umount and it fails because file.so still has the file open. No writing happening, only reading.
Looks like @Aragorn is right. At first I was skeptical, by now I’m sure technology is advanced enough to solve this simple problem, but apparently if you’re using a thumb-sized USB drive, very most likely you will run into this problem.
I have been using two Samsung EVO SSDs these past few days (connecting to the laptop via usb cable), moving files around, sorting, reading, etc… and had no problem unmounting it. Not a single problem. But the thumb-sized SanDisk 32GB will always be held hostage by file.so.
1 Like
Good news everyone! I was bumping into this same issue that I could replicate with an external USB drive and a network share. While the behaviour led me to believe this was a problem with an application (Kate, XnViewMP, Chromium, Dolphin, etc) or perhaps the USB device, I later discovered this is in fact a recently introduced bug with KDE Framework.
Good news because it’s being addressed in KDE Framework 5.81, so hopefully we should inherit the upstream fixes in our next batch of Manjaro updates. 
Hopefully this will solve the issue for most users.
I could 100% reproduce this issue on KDE Framework 5.80 with Kate, XnViewMP, and Chromium browser, and it didn’t matter if the device was a USB drive or a network share. As noted by @Sixtiz above, this also affects iSCSI.
Here are the bug reports for reference:
https://bugs.kde.org/show_bug.cgi?id=434455
https://bugs.kde.org/show_bug.cgi?id=434781
https://bugs.kde.org/show_bug.cgi?id=434797
https://bugs.kde.org/show_bug.cgi?id=434801
https://bugs.kde.org/show_bug.cgi?id=435169
If the problem still persists after KDE Framework 5.81, we should share about it in here and maybe we can submit a newer bug report.
Update your system and test it out now. Looks like the patch (from the bug reports) made it from upstream into the Manjaro stable updates. 