'Safely Dismount' USB drives not working since update from Kodi 17 to 18?

Help and Support Vero 4K / Vero 4K +
1

Hi,

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).

Thanks in advance for any help on this.

RR

2

Can you try with something else like a FAT32 pen drive as a quick test?

Sam

1 Like
3

Hi @sam_nazarko,

Sure, no problem.

I can test this next time I boot the PC and can prepare a test flash drive (my main 32GB pen drive is ntfs).

I’ll test ejecting this ntfs drive also, as it definitely worked before Kodi 18, but I haven’t tried it since the update.

Cheers,
RR

1 Like
4

Finally found a minute to test this @sam_nazarko

I used a 90% full 1FB LG flash drive, FAT32. Booted the vero with the drive already atrached. No other external drives were attached during the test.

Sadly unable to ‘safely remove’ the drive via the File Manager or any context menu.

I may not be able to reply until later tomorrow, but thanks in advance for any insights into this change of behaviour.

5

Ok, will check this out.

Sam

6

Hmmm, wonder if this is what corrupted my 8TB HDD, twice.

7

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.

OSMC skin screenshot:

normal_logging
normal_logging1920×1080 764 KB

8

Thanks for all your efforts on this.
I’ll be at a hospital most of today, but will definitely follow your advice and obtain the logs,

Many thanks,lRR