it’s more “only available to the user mounting it” as on unix/linux more than 1 user can be connected “localy” at the same time not only remote connected…
but it could also be achieved by mounting it in /media. as it’s just a permission setting,
Strictly speaking, you are correct, but most of the common hardware that we’re dealing with here at the forum does not come with multiseat provisions.
Also, I think that the default
udisks configuration is such that it is effectively “the user sitting at the console” who gets access to removable storage devices, since in most
aarch64 machines, those devices are plugged into the chassis’ I/O ports, and the console itself also has its ports directly on the motherboard.
but if you have 2 keyboard, 2 mouse, etc… you can have to 2 xorg session with 2 user working at the same time on the same machine… it’s what I meant…
Yes, but that’s a multiseat setup, and it’ll only work when X.Org is running. The Linux console itself is not multiplexed ─ albeit that efforts have been made (and abandoned again) at creating a multiplexed console.
it can if you have serial terminal connected to serial ports… you can do almost all what you want with linux… at school we had a unix sever with about 30 serial terminal connected to it…
your answer is correct… as it’s multi-user system… to avoid “possible” mounting point confflict, permission issue… all mounted usb device is mounted in a user owned place… and they decided to do it in /run/media/username/…
it could have been /media/username it would not change… just that /run is created at boot then don’t let any artifact when reboot…
and for info command
systemd-path return some path
Thanks for reopening the thread I’ll adhere to what linux-aarhus said and make sure it doesn’t get out of hand. I should’ve figured I was beating a dead horse but since I don’t know the story behind it I’m glad to find out. Please keep it open at least for now.
Yeah I thought about that but tmpfs dirs are usually wiped after every reboot (as the definition of
/run describes so that’s why I wanted to ask. I had no idea systemd was responsible for this. I hate to say it but despite it’s ease of use with enable/disable/start/stop/restart for services I’m starting to see why not everyone is a fan of systemd because for example in this case it gives them impression that my usb stick will be wiped if I reboot my machine. (I know this doesn’t happen but hopefully you get my point)
No, that’s just a duplicate of or substitute to the main console. The Linux console code lives in the kernel, and does not allow for multiplexing. You can have virtual consoles, yes, but considering that Linux ─ the kernel ─ was developed on
x86, multiplexing was never built into the console subsystem. This is one of the things where it differs from proprietary UNIX.
Like I said, alternatives have been under development ─ even by the
systemd developers themselves ─ but they have all been abandoned.
So I´m sitting here and trying to answer my thoughts on this question, too.
But the (easy) answer is still not there, right?
I want to mount:
External HDD, NFS/SMB shares, local (Windows) partitions
WHERE is best practice to mount them in Manjaro?
Just create a /media directory and forget about it? At least this directory is found in many many manuals online. Or mount them in /run/media as Dolphin does it when I click on it? Or maybe in different directories depending on what to mount?
Why aren´t these BASIC questions not answered in the wiki?
I am pretty sure, I am not the only new to Linux user who is annoyed by all this little things not just beeing readable at the official pages…
Oh and I forgot about reading that (at least on Gnome[Ubuntu?]) mounting in some places has an impact on the appearance in the GUI, too. What about KDE?
Hello, do these already give you some answers?
Just going to drop this video resource for people to watch. Chris Titus Tech also has a similar video, but this one’s a good enough starting point for anyone wanting to begin their understanding of the FHS.
For the external HDD, it depends what filesystem is on there, and what you use that device for.
You should first and foremost reconcile yourself with the fact that GNU/Linux is a UNIX-style system, and that you are most likely using your computer along the lines of the Microsoft Windows paradigm. Well, there are things in any modern GNU/Linux distribution that will meet you in that regard, but it’ll never be the same as in Microsoft Windows, because this is an entirely different operating system architecture, and it should be used differently too.
Unlike in Microsoft Windows, UNIX operating systems do not approach storage by way of volumes or “drives”, but rather as a uniform directory hierarchy, which will always look the same to the user, regardless of whether the contents of any particular directory are on the same partition, a different partition, a partition on another physical storage device, or even another computer on the network.
With all of the above in mind, programs are not stored where you would store them under Microsoft Windows, but instead, it has always been one of the characteristics of UNIX that programs are merely extensions to the base operating system, and as such, their files will be installed where the operating system files are installed. This means
/usr/bin for executables,
/usr/lib for libraries, and so on.
As such, an external HDD would normally be regarded as a non-essential component to the hardware ─ e.g. for storing backups. But if you’re coming from the Windows world, then maybe your HDD contains executables, or games, or something else altogether. And you will be approaching your system as a single-user machine, whereas UNIX was designed and intended to be used as a multiuser operating system from the ground up.
Ergo, if your external HDD contains personal stuff, then the best place to mount it would be under your home directory somewhere, and especially so if it has an NTFS filesystem on it, because NTFS does not store POSIX file ownership information or POSIX permissions, and so the ownership and the permissions must be faked and set for the entire filesystem at mount time. Therefore, putting it under your
$HOME and mounting it to a directory owned by yourself ─ as opposed to a system directory owned by the root account ─ would be the best solution.
As for network storage, I would recommend a directory
/mnt/network ─ you could also make a
/srv/network, but that would more typically be for if your computer is the server in the network, rather than a client.
Either way, always remember that Microsoft Windows was originally designed as a single-user platform ─ and most specifically, as a graphical user interface on top of MS-DOS, a single-user and single-tasking operating system ─ whereas UNIX was designed with concurrent multiuser access and a centralized security administration in mind.
There is ample documentation on the web regarding how UNIX systems are organized, and I am planning to write a more elaborate tutorial at some later point in time, but for now, is your friend.
I really appreciate your replys. But I am not looking for an explanation of how the whole unix ecosystem is made and why and so on. I - as a new user - am just looking for some easy and simple guideline. And if I am more interested after that, I surely can inform myself more if I want to. But it´s really not interesting as a simple deskop user of how everything is organized and the ethic behind - I just want to get my stuff done. That simple. Why not giving new users just some “best practices” examples. Like something Aragorn has written but in short and simple way?
I am really willing to get rid of Michaelsoft Binbows but even me as a tech guy with many years of computer experience is finding it way to complicated for that basic tasks as connecting my data storages in the “right” way.
Maybe I can better clarify with some other example:
I want to cook noodles.
There are many ways I can do it. Boiling water with gas, electric oven, microwave, making my own fire with wood, using solar energy and what else.
If I ask you, how to cook noodles.
Don´t tell me about all these options and their economical and ecological reasons etc. Just tell me: Put water in pot and heat it up on your stove. Put noodles in and boil em for x minutes. Best practice for usual use case in todays time.
Hope I am not p…g someone off as English is not my native language. Greetings =)
And I use Qwant as my search engine of choice ^^
I mounted my drives as folders under /mnt. For example /mnt/storage for my storage drive /mnt/backup for my backups drive etc.
There is a program called Disks which can edit the fstab file for you. You go to mount options tell it to mount at startup and in the options you can either allow it to create a mount point using the unique drive id or you can specify a folder that you have created to be the mount point.
gnome-disks from the
gnome-disk-utility tarball? That’s default in most GTK desktop variants of Manjaro if I am not mistaken. I do use that, and would advocate 100% for it but flag handling is garbage, which mandates installing the
gparted tarball for that utility. Never bothered to check if KDE’s
partitionmanager has flag editing.
Perhaps I should then put it in simple terms. You are used to putting stuff together by driving nails into it with a hammer. But GNU/Linux is not held together with nails; it is held together with screws. So, you’re going to have to learn how to use a screwdriver. But you’re not interested in learning how to use a screwdriver. You want to use a hammer.
Well, one could try hammering the screws in place, but it won’t have the desired result, and after a while, it’ll turn out that you’ve ruined everything because you insisted on using a hammer instead of a screwdriver.
Can you see where this is going?
Oh great. Sorry, but I didn’t get the reply notifications. Have to check my settings I guess.
But “funny” that I did find the following “by accident” as looking for information of how to automount:
I am sorry to say - bad idea.
Because the /run tree is a volatile structure created at runtime. Creating mount points in that tree will pose issues at boot time when the mounts are defined in fstab (Gnome disks creates fstab entries).
(How do I get rid of Read Only on all my partitions (even on newly formatted seperate hard drive))
So I was beeing told to use a screwdriver instead of a hammer. But no one told about the places where NOT to screw although they said you could screw wherever you want to.
There is not explicit regarding any mounts or folder structures.
As noted - you can do what ever you want - just know it may conflict with system defaults - which then recommends you stay away from /run/ and /mnt - otherwise you are free to do whatever you like.