After I've installed Kubuntu 13.10 Saucy (was on 13.04 Raring) my extra HDD's simply don't want to mount.

If I try manually mounting them, I get an error message:This led me to a "known" kernel bug: https://bugs.launchpad.net/ubuntu/+s...7?comments=all

So the x-gvfs-show mount option should be turned off (until such time as its dependencies are updated). And it works! ... ... well ... sort of. Only if you don't use the disc label as the mount point. The sdb# / sdc# ... method works fine, haven't tested the id mounts as these are even more problematic due to my setup - let me explain.

You see, I've got around 6 HDD's inside my PC (in addition to the SSD which hold the OS(s)). Sometimes I upgrade the HDDs to larger discs by copying the data to the new disc, then removing the old one and renaming the new one with the same label. Then I have the same mount point (/mnt/<Partition Label>) for the new disc as it was for the old (superseded) disc. This in turn means all my various symlinks work without modification (and I've got many of those and would be highly inefficient to edit each to refer to a new mount point). I.e. rename the new disc so it "impersonates" the old one which is now obsolete, making all other settings work without issue or need of modifications. If I used the id (as per gnome-disks's default mount point setting) or even the sdb# method, I tend to find that it changes every time I replace a disc - which in effect thus makes the whole idea of not having to edit any symlinks moot. So Label mounting is a necessity for me.

However, when I set the auto mount point to use the Label method, I get a further error just before the login screen at boot time: I'm told (once for each of these discs) that it's not ready and cannot be mounted at this time. Then I'm given the option to Skip / Manual recovery, neither allows me to mount at this time. So it's a situation of S, S, S, S, S, S ... type password, no discs available except the root SSD.

But then: after logging in I can manually mount these discs no problem. I can probably automate this process through a login script, but why should this happen now? It was working fine in 13.04. And further: unfortunately though, it then sets the mount point to /mnt/<username>/<Partition Label> ... which obviously then voids all my symlinks.

I don't know the answer to your question, but would mounting using UUID rather than LABEL be a viable alternative?

fstab with uuid

Thanks to the idea. Unfortunately it similar to GUID. I.e. a unique identifier for a particular device.

The problem with that (and why I'm not using it) is that my new HDD (by definition) would have a new GUID/UUID. And therefore a new mount point. Which is exactly what I don't want.

Now if it was only this once, I'd accept trying to find and edit all symlinks to point to the new mount point (together with the paths). But I don't want to run through that again in a year's time (when I can afford a larger disc). I suppose I could write a script or program to do this

Another alternative I've been playing around with is using "nested" symlinks. I.e. the default symlinks (spread throughout many folders in home and through shares) point through a single symlink in media to the relevant /mnt/890248976#####...... partition. That way I would only need to edit one single symlink (the one in media). That I'd be happy to do ... though it brings up another issue:

I was on the point of converting all my symlinks to hardlinks because if I don't then sharing them across samba creates a security hole: http://www.samba.org/samba/news/symlink_attack.html
But that brings up other issues, like hardlinks not being able to link to directories (only files) and not able to cross fs boundaries (e.g. one disc in ext4 and another in reiserfs). Not to mention, it would be even more difficult to edit/re-create hardlinks every time the mount point changes.

Perhaps I should just scrap the entire idea and change to fsunion. Though that would mean lots of reformatting and moving files about - at least to begin with (heard of some issues with fsunion though, so a bit scared of it).

Another alternative might be to go with JBOD. Perhaps going with ZFS/BTRFS instead, but the one's not perfectly Linux and the other is mostly still beta (and I've had issues with ZFS on linux like crashes causing corruption - especially when loads are high due to its extreme RAM requirements). Normal RAID is simply not an option - my discs are definitely NOT the same size.

If I go this route (fsunion / JBOD / spanned fs over multiple HDDs) I'd probably be able to get away from the symlinks. Any other alternatives I could try, or reasons to dispel the warnings which are keeping me from using some alternatives?

um, you are changing drives, therefore you have to make the adjustment. this is a USB device, therefor it will NEVER be static, the uuid is the best way to deal with this.

if you have symlinks pointing to the device instead of to a mount point you are doing it wrong. point to the mount point that will NOT change, then you have zero issues with your symlinks.

1 members found this post helpful.

This isn't a USB disc, it's a HDD connected through a SATA cable direct from one of the mother-board's ports. I.e. I'm swapping an internal HDD for a larger one. If it was a USB it would've been even worse.

Though you're correct (and thanks), I failed to realize that I can actually mount the same drive into multiple locations. So it's immaterial what method its original fstab mounting is pointing to (so I also NOW consider UUID/GUID as the least troublesome). All that's needed is a mount instruction inside rc.local so it mounts that UUID/GUID reference to another point which you can name in the CLI command's switches to anywhere and any name you desire ... and it all works fine! With this I didn't even need to edit any links.

excellent. please mark the thread solved.

yes sorry for some reason i thought this was a USB device, but even with an internal HDD its the same process for the fstab, use either the /dev/sdX# or the UUID and mount it to the same place as the old drive it replaced.

1 members found this post helpful.