No file found on /media after update

Hi All,

After being prompted to do a recent update on my raspberry pi b+ last night I am unable to see any of my external USB hard drives under /media but they all seem to appear ok when i do lsblk:

osmc@osmc:~$ lsblk
sda 8:0 0 465.8G 0 disk
`-sda1 8:1 0 465.8G 0 part
sdb 8:16 0 298.1G 0 disk
`-sdb1 8:17 0 298.1G 0 part
mmcblk0 179:0 0 7.4G 0 disk
|-mmcblk0p1 179:1 0 243M 0 part /boot
`-mmcblk0p2 179:2 0 7.2G 0 part /

Here’s my journalctl log:
and mount:

I’ve been following frankprevi’s thread on here with a similar issue, but my log seems to be throwing up a completely different error:

Sep 05 17:15:34 osmc udisks-glue[294]: Device file /dev/sda1 inserted
Sep 05 17:15:34 osmc udisks-glue[294]: Trying to automount /dev/sda1…
Sep 05 17:15:34 osmc udisks-glue[294]: Failed to automount /dev/sda1: Mount option gid=1000 is not allowed

This all worked fine before I installed the update but I’m not beyond thinking this could be some type of hardware issue, these drives are getting a little old. Any help would be much appreciated, thanks guys.


A couple of questions - how long since you last updated ?

Also what file system is on the drive and is a spinning drive or just a USB thumb drive ?

When changing the udisks-glue service to run as root instead of osmc I see a similar error to you with uid/gid not allowed, which doesn’t make sense…

Something has changed but we are not sure what, whether it is kernel related or whether there has maybe been a debian update for udisks or udisks-glue packages recently - our udisks-glue.conf has not changed between the time when this worked perfectly and stopped working perfectly…

From what I can tell so far the problem is some sort of race condition, where udisks (and therefore udisks-glue) gets called too early before the device node is ready to access. (I can’t reproduce it myself so far - all my USB drives mount OK with the default config)

If you do a warm reboot does your drive mount ? How about if you unplug the USB plug for the drive and reconnect it ? What about if you just restart the udisks service ?

sudo systemctl restart udisks.service

Or what about if you restart the udisks-glue service ?

sudo systemctl restart udisks-glue.service

If you let me know which of the above (if any) cause the drive to mount properly that is quite useful.

Edit: one final question, do you have Samba installed or not ?

Interesting, I probably did a apt-get upgrade a month or 2 ago and things have been fine up until when I ran the OSMC update from the GUI last night, other than that this was the first GUI update I’ve run since installing (July 2nd).

The two hard drives are connected to an external powered USB hub and are old laptop spinning drives.

I tried un/re-plugging the USB cables and the suggested commands with a hot reboot using the following command to no effect:

sudo systemctl restart mediacenter

As for Samba, I havn’t touched it at all so I presume whatever default is? I am running an nginx web-server with PHP and sqlite but I don’t think that’s causing any issues, I haven’t touched the configuration of any of that for a month.

By warm reboot I mean rebooting with ‘reboot’ not restarting the mediacenter service.

You didn’t say what file system they have on them ?

A post was split to a new topic: Not booting after update

Ok, sorry. Tried the above steps again but with the same outcome.

The two drives are both NTFS:

Disk /dev/sda: 465.8 GiB, 500107860992 bytes, 976773166 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1b1d75da

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 976769023 976766976 465.8G 7 HPFS/NTFS/exFAT

Disk /dev/sdb: 298.1 GiB, 320072932864 bytes, 625142447 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdbeca6d5

Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 625139711 625137664 298.1G 7 HPFS/NTFS/exFAT


We have pushed version 1.3.6 of diskmount-osmc - if you check for updates again you should get this. Please try updating and let us know if it fixes your drive not mounting correctly.

No joy, I’m away from the pi at the moment so I ran:

sudo apt-get install diskmount-osmc

and the version number is indeed now 1.3.6 but the problem still persists upon restart. Here’s the logs after the update:


So when I got home last night I tried a number of different combinations of restarting/hot restarting/unplugging and re-plugging with the hard drives/external hub powered up and down and with restarting the services mentioned in the second post, still nothing seems to work.


I have pushed out another diskmount-osmc with additional debug logging, please update to get this, reboot, and when your disk fails to mount please provide the system journal with:

sudo journalctl | paste-log


Installed 1.3.8, here’s the new system journal:


You could provide the output of these two commands please:

blkid /dev/sdb1
udisks --show-info /dev/sdb1 | paste-log

Something seems to be a bit strange with your ntfs partition as the automounter mounts ntfs partitions for me without problems.

Could you try this following please.

Edit /etc/udisks-glue.conf and find the following section of the file for ntfs:

match ntfs-partitions {
        automount = true
        automount_options = { 'fmask=0111','dmask=0000','uid=1000','gid=1000' }
        post_mount_command = '
                if [ -f /usr/bin/net ] && /bin/systemctl is-enabled samba > /dev/null 2>&1; then
                        while [ $count -gt 0 ]; do
                                if sudo /usr/bin/net usershare add "$(basename "%mount_point")" "%mount_point" "Auto-mount Volume" "$(hostname)\osmc:f"
                                        then break
                        sleep 5; let count-=5

Change the auto_mount options line to remove the uid and gid options so that it looks like this:

automount_options = { 'fmask=0111','dmask=0000' }

Then reboot - if I’m right your drive should mount. Please also provide the output of this command so I can make sure the permissions on the mount point are still correct:

ls -al /media

If this all works then I think I know what the problem is and if so it’s an easy fix.

The results from the blkid command:

/dev/sdb1: LABEL="320GB 2.5" UUID="E84243D84243AA60" TYPE="ntfs" PARTUUID="dbeca6d5-01"

udisks --show-info log:

Made the changes to the conf and it worked!! The drives are now showing under /media, here’s the permissions output:

total 80
drwxr-xr-x  4 root root     4096 Sep 10 09:54 .
drwxr-xr-x 23 root root     4096 Jul  2 19:08 ..
drwxrwxrwx  1 osmc www-data 4096 Oct 29  2014 320GB 2.5
drwxrwxrwx  1 osmc www-data 4096 Jul 17 09:30 500GB 2.5
-rw-r--r--  1 root root      232 Mar  6  2015 README

Thanks for all your help DBMandrake, what was the problem in the end, some type of mounting permissions problem?

Aha, I think I see the root cause of your problem - to confirm, please provide the output of the following command:


It looks like you have changed the primary group of the osmc user to www-data, but the id command will confirm this.

Interesting, I added the osmc user into the www-data group back in June as part of my nginx configuration, I was unaware I had made it the primary group overall.

uid=1000(osmc) gid=33(www-data) groups=33(www-data),4(adm),6(disk),7(lp),20(dialout),24(cdrom),29(audio),44(video)

I guess something changed recently causing this to become a big issue? How can I correct the primary group without removing the osmc user from www-data?

Our udisks-glue.conf has evolved a lot over time - at some point the uid/gid mount options were added, which then clashed with your change to the primary group. It turns out that uid/gid are not actually required anyway (I’ve tested it without) and only serve to cause a fatal error if the user trying to mount the drive is not osmc/osmc, so I will remove these options shortly in an update.

Even though I will fix the issue in udisks-glue.conf I would still recommend you change the primary group back to osmc and add www-data as a secondary group - there’s no telling what other subtle breakage it might cause as we have not tested the system with non standard changes to the osmc user account - there may be other assumptions in config files/scripts that will be broken.

To change your primary group back to osmc and add www-data as a secondary group try the following:

sudo usermod -g osmc osmc
sudo usermod -a -G www-data osmc

You will need to log out and back in again to see the change, which you can confirm with the ‘id’ command.

Cool, I sorted out the groups and restarted. ‘id’ now shows:

uid=1000(osmc) gid=1000(osmc) groups=1000(osmc),4(adm),6(disk),7(lp),20(dialout),24(cdrom),29(audio),33(www-data),44(video)

The nginx stuff still seems to be running ok, looks like everything’s back to normal now. Thanks for the help DBMandrake.