Re: /mnt usage

[David Wright]

On Mon 15 Jan 2024 at 21:41:15 (-0800), David Christensen wrote:
> On 1/15/24 20:05, David Wright wrote:
> > And I've never created any mount point under /mnt. For a one time
> > copy, /mnt is handy; always there, I don't have to mkdir at all.
> 
> What about when you have an portable backup drive that you connect
> once a week?  And the drive is encrypted?  And your backup system
> wants to know where?

I plug it in, udev springs into action, and mount points for all
the partitions are created under /media with appropriate names.

The lookup "table" is a set of files under /etc/udev/rules.d/my-mountpoints
where each filename is any string that will only be seen from the new
device or partition, and its content is the name for the mountpoint.
For a partition, the string can be any of:

  # ID_FS_LABEL  for my conventional drives, USB sticks, SD cards, 
etc
  # ID_FS_UUID   for FAT and encrypted partitions, but try to make 
this a legacy option
  # ID_SERIAL_SHORT  for DVD drives, NTFS, and certain other formats
  # ID_PART_ENTRY_NAME   for encrypted partitions on GPT
  # (basename of) DEVNAMEfor unrecognised sticks, cards, etc
  # ID_SERIALfor DVD drives, NTFS, and certain other formats
  # quit after any success.¹

When udev sees a device, a string matching:

  # properties are, in order:
  # ID_SERIAL_SHORT
  # ID_SERIAL
  # quit after any success.

will create a device (typically cdromN, where N depends on which
device) if inserting a data CD or DVD, but also create a symlink
(by stripping off N).

There are currently 59 entries to select from, and the setup is
very flexible. For example, I have a dead USB stick with the
serial number A4000215 that creates a "mountpoint" called
"/media/. PLAY CD". If you place a Red Book CD into one particular
PC and insert that stick, the CD drawer closes and the CD plays.
The player has a 3.5mm socket connected to a HiFi system.
The PC just has to be running for this trick to work, because
a @reboot root cron job is watching /media with inotifywait.
No one has to be logged in, or /home even unlocked.
Pull the stick out and the CD drawer opens again.

> What about when you need multiple temporary mount points?

I can only think of one or two occasions when I use /mnt at all:
the obvious case, a "foreign"/brand-new stick; but also when
I install a new system, I use /mnt for a USB stick that runs
a huge initial install/configure script, which includes
bootstrapping the setup I've just described above.

In your parlance, my accessories are all pets, not cattle.

¹ comments from the rules script.

Cheers,
David.

Re: /mnt usage

[Tom Furie]

hw  writes:

> /tmp is volatile nowadays and not temporary.  That's particularly

Volatile storage is, by definition, temporary.

> braindead when you want Libreoffice to be able to recover files after
> a crash, which, by default, autosaves in /tmp.

/tmp is a terrible place to store recovery data, it's supposed to be
used for transient data, not stuff you might be concerned about getting
back later. Perhaps somewhere under ~/.local would be more appropriate
on a modern system.

Re: /mnt usage

[hw]

On Mon, 2024-01-15 at 21:41 -0800, David Christensen wrote:
> On 1/15/24 20:05, David Wright wrote:
>  > And I've never created any mount point under /mnt. For a one time
>  > copy, /mnt is handy; always there, I don't have to mkdir at all.
> 
> 
> What about when you need multiple temporary mount points?

I create subdirectories under /mnt as needed.

> What about when you have an portable backup drive that you connect once 
> a week?  And the drive is encrypted?  And your backup system wants to 
> know where?

See above :)

Also, see https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf

It's left to the administrator to decide how temporary stuff is with
/mnt.  I use /srv for stuff that is being served by the particular
system.

/tmp is volatile nowadays and not temporary.  That's particularly
braindead when you want Libreoffice to be able to recover files after
a crash, which, by default, autosaves in /tmp.

Re: /mnt usage

[Jeffrey Walton]

On Tue, Jan 16, 2024 at 6:07 AM David Christensen
 wrote:
>
> On 1/15/24 20:05, David Wright wrote:
>  > And I've never created any mount point under /mnt. For a one time
>  > copy, /mnt is handy; always there, I don't have to mkdir at all.
>
> What about when you need multiple temporary mount points?
>
> What about when you have an portable backup drive that you connect once
> a week?  And the drive is encrypted?  And your backup system wants to
> know where?

It depends on the standard you are following. /run/user/$uid is
popular nowadays for systemd systems. In the past, it used to be /tmp.
For systems I control, I set each user's TMPDIR to $HOME/tmp, so they
can do what they want in their own area. Unlike /run, TMPDIR is not
cleared at reboot, however.

Also see . It covers a lot of the
locations, like /tmp and /run.

Jeff

Re: /mnt usage

[Cindy Sue Causey]

On 1/16/24, to...@tuxteam.de  wrote:
> On Mon, Jan 15, 2024 at 09:41:15PM -0800, David Christensen wrote:
>> On 1/15/24 20:05, David Wright wrote:
>> > And I've never created any mount point under /mnt. For a one time
>> > copy, /mnt is handy; always there, I don't have to mkdir at all.
>>
>>
>> What about when you need multiple temporary mount points?
>
> I have /mnt1, /mnt2.
>
>> What about when you have an portable backup drive that you connect once a
>> week?  And the drive is encrypted?  And your backup system wants to know
>> where?
>
> Ah, for specific mounts I have specific points. Encrypted backup goes
> to /media/backup (yes, I "inherited" that from somewhere) and the decrypted
> device gets named backup (thus /dev/mapper/backup).


I zipped on past this talking point yesterday, but since you all gave
it its own thread, grin. I have multiple fstab entries for /mnt, too:
/home, /var/cache/apt/archives, browsers, and just data backup in
general. I do so because those have their own partitions.

The first two, /home and /var/cache/apt/archives, are a two-part mount
in fstab where /mnt/MOUNTPOINT mounts a partition first then a second
mount point points at a usually release-specific child directory as a
"mount -B" kind of thing.

Because of serious PTSD-related cognitive issues where I forget
experiences 10 seconds after they happen, those mount points are all
capitalized so I don't bleep up those /mnt directories by using them
for anything else (e.g. /mnt/HOME, /mnt/APT, etc).

Using /mnt via fstab has been working flawlessly *for me* for probably
3 or 4 years now, so much so that I guess I take its time saving
beauty for granted.

Exiting now while thinking out loud: Proofreading this email before
sending invoked a thought of how installers ask if we have directories
like /var on separate partitions. What are the installers' method of
operations for those instances?

Or do they just presume that the only thing on e.g. /var's dedicated
partition is /var and nothing else (where my personal M/O is to be
filtering through a bunch of [junk] to hit my target child
directories)? My uneducated guess is installers likely a-sume
dedicated partitions. That makes good, much less messy common
sense...

Another proofreading triggered afterthought: I have /mnt/BROWSER, too,
which then secondarily "mount -B" binds to specific browsers' child
directories. I've been having some VERY ODD USB/bus/dbus simultaneous
crashes the last few days (on two different laptops now so it feels
software or outside interference'y).

Having Firefox on its own partition has amazingly been keeping that
part of the USB crashes sane because the mount point partition for
that is deliberately on the same hard drive as the primary Debian
installation. That way, when e.g. an external hard drive crashes, the
browsers remain attached and thus don't lose any irreplaceable recent
browsing history. Thank you for that capability, Developers!

PPS What's mind blowing *to me* about those USB-triggered crashes the
last few days is that /home is part of what crashes, yet that browser
mount bind keeps right on flawlessly ticking until it eventually does
not. I'm most often then able to ALT+CTRL+F3 and make a fast browser
history backup via a root login before rebooting to reconnect
everything again. No complaints, just very grateful it even works long
enough to perp those sanity preserving backups

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with good intentions *

Re: /mnt usage

[tomas]

On Mon, Jan 15, 2024 at 09:41:15PM -0800, David Christensen wrote:
> On 1/15/24 20:05, David Wright wrote:
> > And I've never created any mount point under /mnt. For a one time
> > copy, /mnt is handy; always there, I don't have to mkdir at all.
> 
> 
> What about when you need multiple temporary mount points?

I have /mnt1, /mnt2.

> What about when you have an portable backup drive that you connect once a
> week?  And the drive is encrypted?  And your backup system wants to know
> where?

Ah, for specific mounts I have specific points. Encrypted backup goes
to /media/backup (yes, I "inherited" that from somewhere) and the decrypted
device gets named backup (thus /dev/mapper/backup).

Cheers
-- 
t


signature.asc
Description: PGP signature

/mnt usage

[David Christensen]

On 1/15/24 20:05, David Wright wrote:
> And I've never created any mount point under /mnt. For a one time
> copy, /mnt is handy; always there, I don't have to mkdir at all.


What about when you need multiple temporary mount points?


What about when you have an portable backup drive that you connect once 
a week?  And the drive is encrypted?  And your backup system wants to 
know where?



David