SUMMARY This one is weird. Since updating to the latest TW snapshot with Plasma 5.21.3 and Frameworks 5.80.0, Dolphin seems to read-lock the *first* file being played from an NFS mount by mpv. STEPS TO REPRODUCE 1. mount NFS share 2. play a file with mpv 3. close mpv OBSERVED RESULT Read lock on the file by "file.so" persists. This means you can't delete the file or the folder containing it. Further files played with mpv lose their read lock some time after closing mpv. EXPECTED RESULT Read lock removed SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20210319 KDE Plasma Version: 5.21.3 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 Dolphin 20.12.3 Kernel Version: 5.11.6-1-default OS Type: 64-bit Graphics Platform: X11 ADDITIONAL INFORMATION - playing a file with VLC does not spawn a "file.so" thing. - the following OS/KDE versions do *not* have this problem, and don't spawn a "file.so" from Dolphin either when playing a file with mpv: Operating System: openSUSE Tumbleweed 20210307 KDE Plasma Version: 5.21.1 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Dolphin 20.12.2 Kernel Version: 5.11.2-1-default OS Type: 64-bit Graphics Platform: X11 Some command outputs of the *affected machine*: # lsof /nfs COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME file.so 4389 user 5r REG 0,99 43362444 138809846 /nfs/video.mkv (10.0.0.3:/export) # ps aux|grep 4389 user 4389 0.0 0.0 87696 19244 ? S 18:13 0:00 file.so [kdeinit5] file local:/run/user/1000/klauncherQcszyt.1.slave-socket local:/run/user/1000/dolphinTTHkjd.9.slave-socket (it's still lingering 20 minutes later)
I don't know what the purpose of file.so [kdeinit5] file local:/run/user/1000/klauncherQcszyt.1.slave-socket local:/run/user/1000/dolphinTTHkjd.9.slave-socket even is, since an older Plasma release doesn't even seem to spawn this.
Yeah, this is Bug 434455. *** This bug has been marked as a duplicate of bug 434455 ***