I’ve posted a couple of related topics about behavioural changes I’ve noticed since updating the Vero4K from Kodi 17 to 18.
Currently the ‘safely dismount’ option has no effect on my external usb 3 hard disks, whether attempted from the File Manager, or context menus elsewhere. This has worked perfectly since purchasing the Vero last April (2018), until I updated to 18 in May 2019.
Fdisk shows the drives are still mounted. Ssh and Osmc can read the contents as usual regardless of the attempted dismount. There is no ‘you can safely remove…’ (or similar) message, nor any error message (perhaps in the logs…)
These drives are automounted by osmc (no fstab entries or manual mounting involved), they’re ntfs formatted, and totally unencrypted,
Elsewhere (sorry, I can’t locate the post - it was probably in a reply) I’ve noted that under Kodi 18 these drives no longer enter sleep mode (governed by their own firmware) when idle.
For the record the drives are Seagate 3TB units, all bought at roughly the same time, but on different firmware and hardware, with different sleep mode timeouts.
My other drives are Western Digital, all encrypted (separate topic on this; not sure if they still go into sleep mode).
Tried to reproduce but can’t using an external USB device with MBR + NTFS.
The only way to exactly reproduce it is to have something accessing a file or directory on the drive all the time. In this case you can find in the kodi log (debug enabled + reboot, before) something like
2019-06-25 07:08:36.942 T:4069429248 ERROR: DBus error: org.freedesktop.UDisks.Error.Failed - Error unmounting: umount exited with exit code 32: umount: /media/Medion8GB: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)
So, give it a try and post the log set URL:
You can learn more about how to submit a useful support request here.
Depending on the used skin you have to set the settings-level to standard or higher, in summary:
enable debug logging at settings->system->logging
reboot the OSMC device
reproduce the issue
upload the log set either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A
publish the provided URL from the log set upload, here
Thanks for your understanding. We hope that we can help you get up and running again shortly.