Where should I mount my internal drive partitions?
As far as I searched on the internet, I came to know that
/Media = mount point for removable media that system do it itself ( usb drive , CD )
/Mnt = temporarily mounting anything manually
I can most probably mount anything wherever I want, but if that's the case what's the point of /mnt? Just to be organised I suppose.
TLDR
If /mnt is for temporary and /media is for removable where should permanent non-removable devices/partitions be mounted. i.e. an internal HDD which is formatted as NTFS but needs to be automounted at startup?
Asking with the sole reason to know that, what's the practice of user who know Linux well, unlike me.
I know this is a silly question but I asked anyway.
Anything I add to fstab gets mounted in
/mntand removable drives get auto mounted to/media. Linux doesn't care where you mount your drives, they can be mounted anywhere you want.Linux doesn't care where you mount your drives, they can be mounted anywhere you want.
Thank You
It ultimately doesn't actually matter because in many cases these things are convention and there is no real system-based effect. So while it would be especially weird if your distro installed packages into those directories, it ultimately doesn't matter. Someone already linked the filesystem hirearchy. See how tiny the /media and /mnt sections are?
I put my fixed disks into subdirectories under /mnt and I mount my NAS shares (I keep it offline most of the time) in subdirectories in /media.
fixed disks under /mnt
NAS in /media
Why ? that's what I'm asking. Can't you just put in the same folder and call it a day?
I put my fixed disk in /mnt
My Files, which are inside the partition mounted in /mnt/something has root as Owner. So When I try to move something to Trash, it's not allowing me to do, Only perma delete. When saw properties it said owner is root.
Is it because mounted at /mnt?
Files under /media seems fine. files under /media says it's owner is 'me'
The answer to your question why is because I arbitrarily decided on that years ago. That's basically all there is to it.
The answer to your file ownership problems I can't answer, because I don't have that happening. My files are mounted like so:
LABEL=BigHD /mnt/BigHD btrfs nosuid,nodev,nofail,noatime,x-gvfs-show,compress-force=zstd:1 0 0The answer to your question why is because I arbitrarily decided on that years ago. That's basically all there is to it.
Thanks for clarifying bro
Use any you want. I've been mounting my internal secondary hard drive on /mnt for well over a year now and haven't had any problems. Previously, I mounted it on
~/Storageand it also worked fine (though only because I'm the only user in my computer; dual-user systems would result in the other user being unable to access the hard drive).If I remember correctly mnt is for static media that you expect to always be present and media is for removable media which may come and go.
My Files, which are inside the partition mounted in /mnt/something has root as Owner. So When I try to move something to Trash, it's not allowing me to do, Only perma delete. When saw properties it said owner is root.
Is it because mounted at /mnt?
Files under /media seems fine. and says it's owner is 'me'
Unless dictated by the particular data in the disks, /mnt is generally used for system managed volumes and /media is used for user managed volumes.
If you do something else, stick with it so you don’t get confused.
Not a pro by any means, but I mount my internal drives at /mnt. Its also where I mount my NAS
AFAIK mount point doesn't matter
I decided to simply create directories within /mnt,
chmod 000them and use them as fixed mountpoints;
for manual temporary mounts I have /mnt/a, /mnt/b, ... /mnt/f, but I never needed to use more than two of them at once.While this setup doesn't really respect the filesystem hierarchy, I wouldn't have used /mnt at all if I were constrained by its standard purpose since having one available manual mountpoint seems pretty limiting to me.
Then again, I have 3 physical drives with ~ 10 partitions, plus one removable drive with its own dedicated mountpoint...chmod 000
What does this do? I'm a Meganoob.
Fixed mountpoints
?
having one available manual mountpoint
you mean the whole /mnt is meant to single mount point?
Sorry for all the questions.
Adding to what the other comment explained:
I use
chown 000so that regular users fail to access a directory when no filesystem is mounted on it; in practice it never happens, because "regular users" = { me }, but I like being pedantic.As for /mnt, it is supposed to be a single temp. mountpoint, but I use it as the parent directory of multiple mountpoints some of which are just for temporary use.
I use
chown 000so that regular users fail to access a directory when no filesystem is mounted on itMy dummy brain can't understand it man.
Isn't someone can't access a directory when no filesystem is mounted on it the default behaviour?
No, directories without anything mounted on them are normal directories - which checks out, since you can mount anything anywhere; unlike Windows volume letters, which only exist when volumes are mounted or detected by the OS.
When you mount a filesystem onto a directory, the OS "replaces" its contents AND permissions with that of the filesystem's root.
Here's an example with my setup (hopefully you're somewhat familiar with Bash and the output of
ls -l).Imagine some random filesystem in
/dev/sda1owned by "user" which only contains a file named "/Hello World.txt":$ # List permissions of files in /mnt: $ # note that none of the directories have read, write nor execute permissions $ ls -la /mnt drwxr-xr-x 1 root root 168 May 31 23:13 . drwxr-xr-x 1 root root 128 May 31 23:14 .. d--------- 1 root root 0 Aug 1 2020 a/ d--------- 1 root root 0 Feb 11 2022 b/ d--------- 1 root root 0 Aug 11 2021 vdisks/ $ # No read permission on a directory => directory entries cannot be listed $ ls /mnt/a cannot open directory '/mnt/a': Permission denied $ sudo mount /dev/sda1 /mnt/a $ # List again the permissions in /mnt: the root of /dev/sda1 $ # has rwxr-xr-x (or 755) permissions, which override the 000 of /mnt/a ... $ ls -la /mnt drwxr-xr-x 1 root root 168 May 31 23:13 . drwxr-xr-x 1 root root 128 May 31 23:14 .. drwxr-xr-x 1 root root 0 Aug 1 2020 a/ d--------- 1 root root 0 Feb 11 2022 b/ d--------- 1 root root 0 Aug 11 2021 vdisks/ $ # ... and its contents can be accessed by the mounted filesystem's owner: $ ls -la /mnt/a drwxr-xr-x 1 user user 168 May 31 23:13 . drwxr-xr-x 1 root root 168 May 31 23:13 .. -rw-r--r-- 1 user user 0 Jul 4 22:13 'Hello World.txt' $ find /mnt /mnt /mnt/a /mnt/a/Hello World.txt find: ‘/mnt/b Permission denied find: ‘/mnt/vdisks’: Permission deniedPlease note that me setting permissions is just extreme pedantry, it's not necessary at all and barely changes anything and if you're still getting familiar with how the Linux VFS and its permissions work you can just ignore all of this.
OS "replaces" its contents AND permissions with that of the filesystem's root.
So, the original content is lost forever?
setting permissions is just extreme pedantry
So, what's the actual use case of it though? Even though it's pedantry, it still there has to be some benefits, right?
I mean, What's the need for you to deny the access of
/mnt/auntill has mounted with something? One can just leave it as it is, right?So, the original content is lost forever?
No, but it becomes invisible and inaccessible* as long as the filesystem is mounted over it - see this Stack Exchange question and accepted answer.
The benefits are marginal, for example I can see if a filesystem is mounted by simply typing
ll /mnt(llbeing an alias ofls -lA) - it comes handy with my system due to how I manage a bunch of virtual machines and their virtual disks, and it's short and easy to type.
Some programs may refuse to write inside inaccessible directories, even if the root user can always modify regular files and directories as long as the filesystem supports it.It's not a matter of security, it's more of a hint that if I'm trying to create something inside those directories then I'm doing something wrong (like forgetting to mount a filesystem) and "permission denied" errors let me know that I am.
it's more of a hint that if I'm trying to create something inside those directories then I'm doing something wrong (like forgetting to mount a filesystem) and "permission denied" errors let me know that I am.
Now I understand.
This is all new to me bro.
Even I don't know if I will go this further to explain something to someone.
Thanks Chad.
That depends on your usecase.
I have setup servers where I mounted extra drives on /srv/nfs
When/If I switch to Linux I will probably mount my secondary drives to folders like
/home/stoy/videos
/home/stoy/music
/home/stoy/photos
/home/stoy/documents
/home/stoy/games
The ~/games will probably be an LVM since it contains little critical data and may absolutely need to be expanded to span several drives, though I would also be able to reduce the size of it and remove a drive from the LVM if needed.
I'd make a simple conky config to keep track of the drive space used
I'd just keep using the default automount spot for automounting drives.
My /home is also on a separate filesystem, so in principle I don't like to mounting data under there, because then I cannot unmount /home (e.g. for fsck purposes) unless I unmount also all the other filesystems there. I keep all my filesystems on LVM.
So I just mount to /mnt and use symlinks.
Exception: sshfs I often mount to home.
So you suggest not to mount like the guy above said
/home/stoy/videos?And suggest symlinks instead?
Yes, just mount to
/mnt/videosand symlink that as needed.I guess there are some benefits in mounting directly to
$HOME, though, such asfind/fdwork "as expected", and also permissions will be limited automatically per the$HOMEpermissions (but those can be adjusted manually).For finding files I use
plocate, though, so I wouldn't get that marginal benefit from mounting below$HOME.
If I'm not wrong LVM is a method which joins all your disk into single storage pool.
Let's say I stored data all across my LVM, now I suddenly remove one of the disks. What happen now?
Also can I add more disks to LVM later?
Yep, LVM is basically a software raid 0, I used it when setting up Linux server VMs for years at my last job, as far as I know they are still running fine.
The VM system backed up all VMs regularly, so I used LVMs as it made increasing the storage on a server easier for me.
Since it is just a raid 0 that can span several disks and one disk failiure can bring it down I don't want any irriplacable data on it, so games from Steam seems like an excellwnt idea.
That also means that being able to just have a volume spanning several disks would be an easy and simple way to increase storage when space is running tight.
I am an avid hobby photographer and I would never trust an LVM without some kind of added protection, I am looking to get a Synology NAS with minimum of four drives raided in raid 5.
I have a very old Intel NAS with used drives that I used for many years, but I don't trust it anymore, I keep it powered off as a cold backup.
Mount them where you need. Not
/mntand not/media. Maybe/varor its subdirectory, or/srv, or/optdepending on what kind of data you want to store on that partition.Not
/mntand not/mediaWhy though?
what kind of data
Just media files, downloads, images , music kinda stuff.
Why though?
The filesystem is organized to store data by its type, not by the physical storage. In DOS/Windows you stick to separate "disks", but not in Unix-like OSes. This approach is inconvenient in case of removable media, that's why
/mediaexists. And/mntis not suited for any particular purpose, just for the case when you need to manually mount some filesystem to perform occasional actions, that normally never happens.Just media files, downloads, images , music kinda stuff.
That's what usually goes to
/home/<username>. Maybe mount that device directly to/home? Or, if you want to extend your existent/homepartition, use LVM or btrfs to join partitions from various drives. Or mount the partition to some subdirectory of/home/<username>, or even split it and mount its parts to/home/<username>/Downloads,/home/<username>/Moviesetc. So you keep the logic of filesystem layout and don't need to remember where you saved some file (in/home/<username>/Downloadsor in/whatever-mountpoint-you-use/downloads).mount the partition to some subdirectory of
/home/<username>, or even split it and mount its parts to/home/<username>/Downloads,/home/<username>/MoviesetcThanks bro. I think that's what I'm gonna do.
The Linux FHS does not address this, so it's up to you where to mount it. There is no correct choice, but if you want to follow standards just mount it inside /mnt which is the nearest use-case (/media could be automatically used by your DE, so avoid it). Otherwise you can just create a custom folder in root like someone else suggested.
Take a look at FHS spec.
Edit:
On arch forum someone suggests /mnt/dataThank You.
Otherwise you can just create a custom folder in root like someone else suggested
My Files, which are inside the partition mounted in /mnt/something has root as Owner. So When I try to move something to Trash, it's not allowing me to do, Only perma delete. When saw properties it said owner is root.
Is it because mounted at /mnt?
Files under /media seems fine. files under /media says it's owner is 'me'
/mnt/something has root as Owner. So When I try to move something to Trash, it's not allowing me to do
You have to change permissions or owner of that folder (not /mnt itself but the subfolder "something").
If I'm not wrong changing permissions is enough to use gui "move to trash", you can use chmod thru cli (man chmod) o your gui file manager with root privileges.If you want only your user be able to read/write to that disk, then change the owner using chown thru cli (
man chown) or again your gui file manager.So, if I use
chmod, I get the access and other users (if any) are free to do so.In case of
chown, I get the full access and others can't gain access unless I permit.Right?
On Linux files and folders have permissions info for owner, group and everyone else. So you can set individual permissions for these.
By setting the owner to root, if you want to make your user able to read/write that folder, you must either give permissions to everyone to read/write OR assign a group to the folder, give the group permissions to read/write and add your user to that group.
If you instead set your user as the owner of the folder, you can make only your user able to read/write without other fuss.
If you are a newbie, stick to gui file manager. Can you please tell me what file manager are you using? Most of the time you can change permissions thru right click > propriety > permissions.
If you instead set your user as the owner of the folder, you can make only your user able to read/write without other fuss.
Thanks for the tip.
Can you please tell me what file manager are you using?
I'm using Nemo. As it's the default one on Mint Cinnamon.
that is what the
/srvmount point is for. I mount all my external HDDs from there.That is for “Site-specific data served by this system” like /srv/www. Can mount anything anywhere of course.
/srvcontains site-specific data which is served by this system.https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#srvDataForServicesProvidedBySystem
I'm an OpenBSD user, but it shouldn't be hard to translate this to Linux:
If the partition I want to mount is
/dev/sd0i, and sd0's UID/DUID is3c6905d2260afe09, I mount/dev/sd0iat/3c6905d2260afe09.i. fstab entry looks like3c6905d2260afe09.i /3c6905d2260afe09.i ffs rw,whatever_flags 0 0Ik bro, but having whole bunch of random numbers as mount point seems less intuitive to me.
well diskletters/numbers can change between boots and hardware configurations, and unless you have a good label for the partition, this is the only way I can think of to name your permanent mount points that isn't problematic/incorrect in some other way. This will always work correctly with any amount of partitions with any amount of disks; and it's not exactly hard to get the DUID of a disk, at least on OpenBSD. It's also highly scriptable as such.
