Name of USB HDD shown in OSMC (automount, disk label, hfs, udev)

Hi there and at first a happy New Year 2016!

I am pretty new to the whole Linux stuff and really do not have to much of a clue about it so i thought i’d better ask someone with more insight and hope to find an answer to the following question:

I have an external hdd connected to my rasp pi 2 running OSMC. The drive is HFS+ (as I am aware of the read-only topic, it is formatted as not journaled so everything works quiet fine) and it automatically shows up / mounts as follows under /media:
osmc@osmc:/media$ ls 5e929917-f55d-3582-b1d6-97efdd2338b2 EFI README

Obviously the HDD shows up with its UUID and I am asking myself if it is possible to get the name of the PARTLABEL shown instead of the UUID which would be much nicer and easier to remember.

How could this be done? Any hints?

I’ve no longer included the HDD into the /etc/fstab as strange things were happening on my previous attempts (settings previously done were gone, hang on reboot, home directory no longer shown, hdd shows only EFI section and other things i really did not appreciate).

There are so many totally different hints on google on how to implement an HDD to etc/fstab that i really do not know on how to do it properly. Among others so far I tried the following:

UUID=5e929917-f55d-3582-b1d6-97efdd2338b2 /mnt hfsplus nofail,defaults 0 0
UUID=5e929917-f55d-3582-b1d6-97efdd2338b2 /mnt hfsplus force,rw,default 0 0

Could someone maybe help on the /etc/fstab topic and (to me even more important) on the partlabel / UUID shows?

Thanks in advance,

Why are you using HFS+? As I understand it this is a proprietary Apple protocol so is the work of the devil :stuck_out_tongue:
ext4 more suitable?

Why did I knew this would be the first question? :wink:
I am using HFS+ as quiet a large part of my infrastructure is devil-related and from time to time I just need to get the HD connected to an Apple device. Disadvantages of any file-format other than HFS+ are just a pain in… to my certain network.
If I would have known better years before… Anyway, reformatting, etc. is just not an option for me.

ok I like your sense of humour/humor but I would say bin the HD!
You say reformatting is not an option but what happens when the damn thing fails!?:scream:
Sorry I cannot be anymore help but I wish you a happy and prosperous 2016 :smiley:

every hd could fail, right?! :wink:
worked quiet nice under openELEC that I used before but as I like OSMC much better…
so i guess there should be a way, otherwise it wouldn’t have worked before.

btw: same to you! happy 2016 :slight_smile:

Try plugging the drive into a Mac and renaming it in the Finder.

UUID is only used for the mount point if there is no volume label.

I have an external drive that has an HFS+ partition and the name is detected correctly in OSMC.

Hi Mandrake,

thank you for your reply and a happy new year to you.

The HDD already has a volume label. In the finder as well as in OpenELEC. How did you implement the HDD in OSMC? Via etc/fstab? If so, could you please tell me how you did that? As I wrote above, I did not manage to do it right so far and there are tons of different how-tos on google which are different from each other.

Thanks again. Very much appreciated! :slight_smile:

via blkid I got this:
/dev/sda2 UUID="5e929917-f55d-3582-b1d6-97efdd2338b2" TYPE="hfsplus" PARTLABEL="BigAgent" PARTUUID="679f7e07-11f1-4dd6-9185-fadfc5d00beb"

I just connect the drive and let it auto mount.

Can you provide a copy of your system journal after booting with the drive connected ? You can do this through My OSMC log uploader or using the grab-logs command.

Sure. Here you go:

once more here is the complete output of blkid
osmc@osmc:~$ blkid /dev/mmcblk0: PTUUID="000f0776" PTTYPE="dos" /dev/mmcblk0p1: UUID="4D32-1997" TYPE="vfat" PARTUUID="000f0776-01" /dev/mmcblk0p2: UUID="a8f4def4-cc8d-4241-baff-6694b359e9a7" TYPE="ext4" PARTUUID="000f0776-02" /dev/sda1: LABEL="EFI" UUID="5F66-17ED" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="2199d102-2bb7-4a58-9f5a-1bc55cfa9cfa" /dev/sda2: UUID="5e929917-f55d-3582-b1d6-97efdd2338b2" TYPE="hfsplus" PARTLABEL="BigAgent" PARTUUID="679f7e07-11f1-4dd6-9185-fadfc5d00beb"

The issue seems to be PARTLABEL vs LABEL.

Your HFS+ drive has a PARTLABEL which is a label in the actual partition table itself, something which I think you can only have with a GPT drive. My drive is MBR partitioned (as it has FAT32/NTFS partitions on it as well) and thus has a LABEL, which is stored in the filesystem within the partition, not in the partition table.

Here is my blkid:

osmc@rpi2:~$ blkid
/dev/sda5: UUID="b5077a7d-e42f-37b2-bed2-78c71bebd8b8" LABEL="HFS" TYPE="hfsplus" PARTUUID="9734dafc-05"
/dev/mmcblk0p1: UUID="E41A-EA0D" TYPE="vfat" PARTUUID="00095b1c-01"
/dev/mmcblk0p2: UUID="bc561294-055e-4d66-8ad4-9d82ac78ed37" TYPE="ext4" PARTUUID="00095b1c-02"
/dev/sda1: LABEL="FAT32" UUID="189C-FF8D" TYPE="vfat" PARTUUID="9734dafc-01"
/dev/sda2: LABEL="EXFAT" UUID="9E85-5089" TYPE="exfat" PARTUUID="9734dafc-02"
/dev/sda3: LABEL="NTFS" UUID="88BEC748BEC72D8E" TYPE="ntfs" PARTUUID="9734dafc-03"
/dev/sda6: LABEL="Ext4" UUID="af22c373-b468-4e84-815b-0c269c6480e1" TYPE="ext4" PARTUUID="9734dafc-06"
/dev/mmcblk0: PTUUID="00095b1c" PTTYPE="dos"

You can clearly see /dev/sda5 has LABEL=“HFS” (yes I did name the partition that on purpose) and has no PARTLABEL.

It mounts correctly as /media/HFS:

osmc@rpi2:~$ ls -al /media/
total 60
drwxr-xr-x  7 root root  4096 Jan  1 21:00 .
drwxrwxrwx 23 root root  4096 Nov 18 20:25 ..
drwxrwxrwx  1 osmc osmc 32768 Jan  1  1970 EXFAT
drwxrwxrwx  5 osmc osmc  4096 Jul  7 15:03 Ext4
drwxrwxrwx  6 osmc osmc  8192 Jan  1  1970 FAT32
drwxrwxrwx  1   99   99    14 Sep 22 22:56 HFS
drwxrwxrwx  1 osmc osmc  4096 Jun 14  2015 NTFS
-rw-r--r--  1 root root   232 Mar  6  2015 README

There is some discussion on PARTLABEL vs LABEL here:

Maybe on a GPT drive a Mac (or only recent versions of Mac OS) it only writes a PARTLABEL and not a LABEL - I don’t know. I formatted my HFS+ partition on a Mac running Snow Leopard.

If you check in Disk Utility on the Mac you may be able to update the label of the file system in the partition itself. If the Disk Utility GUI can’t do it the diskutil command line tool might have an option to do it, or there may be a linux utility that can change the volume label in an HFS+ partition.

In any case it appears that udisks-glue can’t use a PARTLABEL on a GPT formatted disk. As udisks-glue is no longer maintained by anyone and has not been for quite some time this is not going to be fixable unless we switch to a different automounter.

I was also already wondering not to find any LABEL on the disk. Formatted it quiet a time ago (I guess it was snow leopard as well) as HFS+ non-journaled and, as you mentioned, as GPT. After your kind reply I was doing some research on labels and OS X / GPT but could not find any helpful hints about it. I also tested disk utility that just seems to give info on UUID (and OS X specific identifiers) but does not provide any command to even show -apart from modify- a LABEL.
I switched from openELEC where I faced the same phenomena under release 5. Since the release of Isengard (and with it v 6 of openELEC), the HD was shown properly by its name and no longer by UUID. Seems though they have changed the automounter.

I also checked on udev. There seems to be a possibility to use partitions label but there is no statement on if this also works with GPT / HFS+. The english wiki did not help too much but just in case you are interested, here‘s the link.
Though the german wiki states the following method:


KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"

# Do not mount devices already mounted somewhere else to avoid entries for all your local partitions in /media
ACTION=="add", PROGRAM=="/bin/grep -q ' /dev/%k ' /proc/self/mountinfo", GOTO="media_by_label_auto_mount_end"

# Open LUKS partition if necessary
PROGRAM=="/sbin/blkid -o value -s TYPE %N",  RESULT=="crypto_LUKS", ENV{crypto}="mapper/", ENV{device}="/dev/mapper/%k"
ENV{crypto}=="", ENV{device}="%N"
ACTION=="add", ENV{crypto}!="", PROGRAM=="/usr/bin/xterm -display :0.0 -e 'echo Password for /dev/%k; /sbin/cryptsetup luksOpen %N %k'"
ACTION=="add", ENV{crypto}!="", TEST!="/dev/mapper/%k", GOTO="media_by_label_auto_mount_end"

# Global mount options
ACTION=="add", ENV{mount_options}="noatime"
# Filesystem-specific mount options
ACTION=="add", PROGRAM=="/sbin/blkid -o value -s TYPE %E{device}", RESULT=="vfat|ntfs", ENV{mount_options}="%E{mount_options},utf8,gid=100,umask=002"

# Get label if present, otherwise assign one
PROGRAM=="/sbin/blkid -o value -s LABEL %E{device}", ENV{dir_name}="%c"
# Use basename to correctly handle labels such as ../mnt/foo
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"

# Mount the device
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/mkdir -p '/media/%E{dir_name}'", RUN+="/bin/mount -o %E{mount_options} /dev/%E{crypto}%k '/media/%E{dir_name}'"

# Clean up after removal
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'"
ACTION=="remove", ENV{crypto}!="", RUN+="/sbin/cryptsetup luksClose %k"
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/rmdir '/media/%E{dir_name}'"

# Exit

I don’t know yet, if that might be of any help and so for now I hope for future releases of OSMC where there might be a different or modified autoloader (or a version of udev) that also supports GPT volumes with HFS+ filesystems in a maybe slightly more comfortable way.

In case you (or somebody who is stumbling about this post) has further info, I d very much appreciate to get additional insights. If I find a solution (which i’d consider highly doubtful), I ll let you know.

Thank you for your kind help and the time you took for explaining. Keep up the good work and have fun doing so.


I think OE use udevil for their automounter, called directly from udev rules.

We started work on switching automounter from udisks1/udisks-glue to udevil/devmon but ran into some significant obstacles so due to other more pressing issues it has been put on the back burner for now.

1 Like