Hi,
i just upgraded my 12.2 to 12.3 beta/rc and noticed, i cannot mount usb thumbdrives without the root passwd. and WTF is the /var/run/media/$USER/$ID ********. I want /media/$id for single user systems?
any ideas to fix that?
Did you report the former?
As for the latter, I do not think it is configurable. You of course can open bug report or feature request so at least it can be discussed, but it is upstream decision so you are better off discussing it upstream first.
Linux isn’t a single user system. All things designed for it should take into consideration that many users can be loged in at the same time.
I’m sorry, but I fail to understand why multiuser system cannot have removable mount points under /media.
Now you say something different then above. You asked
I want /media/$id for single user systems
Which simply isn’t applicable because we are talking here about a multi-user system.
And for your new question above, I only can give you an explanation on how it functions. I will not go into all possibilities to design a different solution the then the one that we see here on Linux (and I am afraid you have to live with it unless you design a better solution yourself).
File systems in Unix/Linux systems are normaly mounted by processes that are owned by root. E.g. by typing (u)mount commands from a root owned shell, or at boot by consulting the /etc/fstab file. The end-user of the system is not involved.
From the emergence of desktop computers (PCs) we have the situation that the end-user wants to (de)attach all sorts of storage devices (floppy disks, USB stickies, USB disks, CDs, DVDs) during his session. And that end-user finds it at least cumbersome to “become root”, decide where to mount the device, find out what options to use, etc. Very often that end-user does not even have the knowledge to do this.
The solution designed for this amongst other things uses a special directory /media to create the mountpoints needed. This evolved. Nowadays /media is even a temporary RAM file system so that any leftovers in it (one of the earlier problems) are removed from time to time. These mountpoints are to be of no interest to any end-user. The end-user works through his desktop (device notifier popup and his file manager or other applications). There the device will be shown regardless of it’s mountpoint. No need to know (and that is where an operating system is for: hide the hardware from the user).
The incorporation of a userid in the path to the mountpoint also grow over time as solutions were searched for the fact that more users can be loged in and who is the one that attached the device? This is specialy important when the device contains a non-Linux file system, where protection using userid and groupid is not available.
HTH in understanding. As said, I think you have to live with it. Either mount devices as system manager (and an prophylactic entry in /etc/fstab will prevent the Desktop mechanism to mount it), or let the Desktop do it for you and use the Desktop to access it.
SuSE and then openSUSE have had a policy for many years of complying with the LSB/FSH. There is a Linux Foundation wiki entry for this http://refspecs.linuxfoundation.org/FHS_2.3/ and a Wikipedia entry
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard This is not just an openSuSE issue, and has been discussed in the mailing lists of several distributions, e.g. Gentoo and Fedora.
In short “/media” is a physical directory and is intended to host the mount points for fixed devices with changeable media. E.g. “/media/floppy”, /media/tape0", and “/media/cdrom”. There are good reasons to mount ephemeral devices in a tmpfs, i.e. “/var/run” where they will not persist between sessions. Besides being tidier, there are some security benefits. The “average” user of a graphical desktop would find their USB/SD memory in “Places” within Dolphin, or “Available” Media" in Krusader, etc.
This also “feels” more logical when using a thin-client or remote desktop client to access a virtual or other remote desktop.and the removable device is local.
On 2013-02-12 14:16, hcvv wrote:
> The incorporation of a userid in the path to the mountpoint also grow
> over time as solutions were searched for the fact that more users can be
> loged in and who is the one that attached the device? This is specialy
> important when the device contains a non-Linux file system, where
> protection using userid and groupid is not available.
Using “/media/userdid/mountpoint” can be reasonable, but
“/var/run/media/$USER/$ID ********” is not.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
That’s a sane argument. Which incidentally has little to do with OS being multiuser or not 
For majority of desktop users this is irrelevant. These systems never have more than one user logged in at a time (and often never more than one user at all), so for all practical purposes and definitions it is single-user system.
I am seeing it mounted at both “/run/media/$USER/$ID” and “/var/run/media/$USER/$ID”
I’m not sure why you see this as a problem.
In your home directory, you can create a symlink:
ln -s /run/media/$USER media
and, thereafter, you will be able to see mounted volumes as media/$ID (under your home directory).
It is not important if it is irrilevant to somebody. It is a fact. And as long as it is not understood by at least the person that manages the system, (s)he will have a lot of understanding problems. I see time and again that people do not understand the difference between system configuration and end-user (mostly desktop) configuration where the last is on a per user base and thus need no root access. They stumble around in the dark here because they do not understand this (or refuse to understand this).
You may see this as a drawback of Unix/Linux compared to e.g. Windows. But that is how it is. And you made the choice to use Linux and not Windows.
Only “/var/run” is part of the current FSH. Lennart Poettering introduced “/run” as a secondary mount point for “tmpfs” as part of systemd (see the 12.2 release notes) so as to promote the availability of tmpfs early in the boot process. My personal preference would be for:
ln -s /var/run/media/$USER ~/media
Sorry I only quote the last enty, but this is failed by install-time. All of the home users either trust all users playing on their system (cause else they have to hide their usb thumbdrives) or use the system as single user. Why shouldn’t it be possible to apply user/group rulez to the directory /media/$USBTHUMB instead of that long bullsht name. Even with more users on one system ONE can not access /home/$ANOTHERUSER but /home/$ME - thats the same. If for some reason there IS any need for special treatment of (true) multiuser systems, it should be asked at install-time…auto-login also works on single user systems and do not on multi user systems. Sorry to say, but most of that Poettering stuff is academic treated bullsht and complicates life of the single user machine by changing working stuff to “theoretical perfect enviroment”. - yes, i point to that pulseaudio ****
If everybody trusts everybody, then presumably everybody knows the root password, so everybody can open a terminal session and mount the usb just about anywhere that they like.
Where’s the problem?
The whole story there does not provide much information, but my guess is that it is about a non-Linux file system.
When there is a Linux file system on the device access is granted through the same rules as all other file access (by user/group/other for read/write/execute by using chown and chmod). But the complicating factor here is not the mounting through udisk2 (or any of it’s predecessors) but the mimicing of ownership and access rights when mounting non-Linux (VAT, NTFS, etc) file systems.
The udev2 mount mechanism in these cases not only mounts while interacting with the user on the “active session” (for which I do not have the real definition, but it is something as the localy, vs. remote, session that is on the then shown logical screen), but it also uses that user and his default goup in the mount options to mimic the Linux ownership on the non-Linux file system. And it sets the, again mimiced, access bits to protect against other users. (The uid=, guid=, fmask= and dmask= options of the mount). As you should know there is no way to change these ownership/access parameters then through a new mount command. And chmod and chown do not act dynamicaly on mount parameters as the real fields to change are not in the non-Linux file system.
The only way to use less restrictive fmask= and dmask= parameters on mount (apart from mounting outside the udev2 mechanism) would be through udev2. But I do not know if udev2 is configurable for this goal.
I find the arguments for using /var/run/$USER/media valid. Though I am annoyed.
On the other hand, having both /var/run and /run is moronic.
I have made symlink on all mounted USB drives into /media (so that everything(program) would expect to find things where it was before the upgrade). Though I liked the suggestion to create symlink of media into ones home directory.
FWIW, there’s an interesting discussion on this subject in a Debian bug report concerning udisks2 behaviour:
#680403 - udisks2 mounts devices in a non-FHS-compliant directory - Debian Bug report logs](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680403)