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
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
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 /
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.
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.
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:
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
count=120
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
fi
sleep 5; let count-=5
done
fi'
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.
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.
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.