[ale] Mount extra partition under the /media subdirectory at boot
Michael H. Warfield
mhw at WittsEnd.com
Fri Aug 3 16:43:50 EDT 2012
On Fri, 2012-08-03 at 11:40 -0400, Tom Freeman wrote:
> With appologies to one and all. This is documented somewhere in my old
> notes which are somewhere in a big home cleanup initiated by adult
> children who think their old man needs more than all the help he can get.
> Well, the children are probably right. But the main machine for the house
> died dead, and I need it working with the old files.
> Of course, if there is a better way to do this...
> Essentially, in the past I have used a dirt standard install (Fedora in
> the past, Centos this time), with the children's accounts created on
> /home, which is it's own partition. Since I also host several GB of family
> pictures and such, for use by said children and myself, I created a large
> partition which mounted under the /media directory at boot time. As I
> recall, (personal notes are missing), I assign ownership to
> nobody:nobody, with permissive permissions to each of the files, and dump
> all those shared family files into a hierarchy /media/media.
If you are going to mount things at boot time I would NOT use /media!
Classically, that's what /mnt is for. Reserve /media for dynamic mounts
through udev and that whole subsystem through to the UI. If you have
system related stuff (opt, export, srv) then mount then in their correct
root directories. If you've got something non-transient, like a
permanently connected USB drive, I would definitely make it in /mnt.
Then you can add entries to your /etc/fstab file like these:
LABEL=FUJI /mnt/Fuji vfat defaults,noauto,user 0 0
LABEL=OLYMPUS /mnt/Olympus vfat defaults,noauto,user 0 0
LABEL=EVO /mnt/EVO vfat defaults,noauto,user 0 0
LABEL=Kindle /mnt/Kindle vfat defaults,noauto,user 0 0
LABEL=Terabyte /mnt/Terabyte auto defaults,noauto,user 0 0
UUID=16868893-6b15-49a7-9282-686d0d085aee /mnt/Archive1 auto defaults,noauto,user 0 0
UUID=9acdeea0-5fb6-4b08-a0b8-0948e833a07b /mnt/Archive2 auto defaults,noauto,user 0 0
UUID=f115baca-83c9-4b7a-9534-03c9cc4416f4 /mnt/Archive3 auto defaults,noauto,user 0 0
UUID=8118085e-4d57-4c5a-9473-b08d8e61bf12 /mnt/Archive4 auto defaults,noauto,user 0 0
That's a mix of lables and UUIDs but came from an actual system that
included my various cameras (I've labeled the VFAT file systems) and
whatnot. Those "Archive" drives are actually encrypted drives and the
UUIDs are pointing at the UUID of the LUKS container.
> Almost certainly not the canoniacal (sp?) way to approach the problem, but
> it has worked for several years. Except that I'm needing to rebuild
> hardware at the same time getting ready for teaching a new class at
> school. (Time for fixing stuff is in short supply at the moment.)
> Memory claims there is some approach using a "label" command, and
> something else to get this partition to automount at boot. I'm just not
> finding the documentable details at the moment...
For ext* fs - e2label does the trick or use the -L option at the time
you build the fs with mkfs.ext?. For VFAT, you want mlabel or -n to
mkfs.vfat.
Add your fixed entries to /etc/fstab with "defaults,noauto,user" and
anyone can mount and unmount them as they wish. If you WANT them
mounted at boot time (which I don't really recommend for external
drives) then drop the "noauto" and add some fsck cycle numbers for
checking (assuming something != FAT).
If you REALLY want to do it right, though... Use autofs. Only mount it
when you need it and nobody has to "mount" the bloody thing. It's not
that hard to create an automount map file to map a path to a location.
You can then boot the system up without it and it will be there (if it's
there) when you want it (or give you an error if it's not there). Most
of my NFS stuff goes through /net, which is predefined, but you can
create maps for just about anything - CIFS, SSHFS, hard devices, etc,
etc... I think under autofs.misc you can find examples for floppies
(Gods that be! Is there anyone still using those damn things???) and
CD-ROMS.
Just install autofs and look at the /etc/auto.* files.
> If anybody has an appropriate clue bat to beat me with, and the energy to
> weild it - I shore would appreciate it. Meantime, back to coursework and
> searching...
> Thanks to one and all for putting up with me
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20120803/c69f899d/attachment.bin
More information about the Ale
mailing list