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.

  • Sonotsugipaa@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    5 months ago

    I decided to simply create directories within /mnt, chmod 000 them 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…

    • gpstarman@lemmy.todayOP
      link
      fedilink
      arrow-up
      2
      ·
      5 months ago

      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.

      • Sonotsugipaa@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        2
        ·
        5 months ago

        Adding to what the other comment explained:

        I use chown 000 so 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.

        • gpstarman@lemmy.todayOP
          link
          fedilink
          arrow-up
          2
          ·
          5 months ago

          I use chown 000 so that regular users fail to access a directory when no filesystem is mounted on it

          My 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?

          • Sonotsugipaa@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            5 months ago

            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/sda1 owned 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 denied
            

            Please 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.

            • gpstarman@lemmy.todayOP
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              5 months ago

              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/a untill has mounted with something? One can just leave it as it is, right?

              • Sonotsugipaa@lemmy.dbzer0.com
                link
                fedilink
                English
                arrow-up
                2
                ·
                edit-2
                5 months ago

                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 (ll being an alias of ls -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.

                • gpstarman@lemmy.todayOP
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  5 months ago

                  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.