How do I give read/write/execute permission to myself for newly partitioned SSD and Harddrives?

Update literally just as I posted I tried to do permission via the filepath, and that did actually work: sudo chmod g+rwx /run/media/{username}/ChunkyHDD and that did update the permissions for group but it seems as if I still don’t have read write access for that drive in the same way I do my home drive where the OS is installed.

I will have a read through of what has been posted so far though as well while I am at it.

You are just change group permissions - because a newly formatted device is owned by root you need to use other and remember --recursive flag

chmod o+rwx /run/media/{username}/ChunkyHDD -R

or you could chown the path to your username:group

Ah, I’ll give that a shot now, I actually tried to avoid updating anything but group as I was told in another forum to avoid giving the permission to other for security reasons, I’ll give that a shot now though.

First of all, welcome to the forum :wink:

That is because you are trying to use a disk label and not a file or directory name.
See: man chmod and probably man chgrp :wink:
Also read [root tip] [How To] Use systemd to mount ANY device like @linux-aarhus gave abve…


Welcome to the forum! :slight_smile:

First of all, you have to understand how these things work. GNU/Linux, like all UNIX systems, does not use drive designations. Volumes are always mounted somewhere into the directory tree.

Now, the thing is that if you add some hard disk partition to your existing installation without setting anything up yourself, then the udisks2 subsystem of systemd will treat those volumes as removable storage, and they will then be mounted to a directory under /run somewhere.

The best way to set things up with consistency is to create a static mountpoint for the volume, and to add the information for that mountpoint to /etc/fstab. If you want to use the new volume as an extension to your own home directory, for personal files, then you should create a directory (“folder”) as a mountpoint under your $HOME ─ e.g. /home/your_user_name/Files ─ and to add a line for that in /etc/fstab.

Use lsblk to find out the UUID of the new volume, and then use that in /etc/fstab, like so… :arrow_down:

UUID=some-long-string-here   /home/your_user_name/Files   ext4  auto,nofail,defaults   0  0

For more information, see… :arrow_down:

man 8 mount
man 5 fstab
1 Like

Ah I see, so even if I was to update the permissions via chmod then it would reset after I start it back up again because its not a static mount point? Have I got that right?

I will give the static mount that @linux-aarthus posted a shot once I get back in a few minutes, I’ll update when I have done so.

Thanks for help so far!

That is correct - but if you are the only user on the system it is pretty safe.

If you go down the restrictive path - it would be - and then the permissions will match

sudo chown $USER:$USER /run/media/{username}/ChunkyHDD -R

You might instead suggest that new linux users learn how to do that using mount units of systemd…

That is correct, yes. The entire content of /run lives on a tmpfs, a virtual-memory-based filesystem, and so all of the directories (“folders”) on there are recreated at boot. As such, changing the permissions on anything there would only last until you reboot.

Yes, but /run/media is not static. It exists only in memory. Better choose a static mountpoint.

Personally, I disapprove of using systemd for that, for two reasons…

  1. You don’t know what it’s doing or how, and you don’t learn how to do it right, so it’s also difficult to troubleshoot.

  2. systemd aims for the stateless machine, and in a stateless machine, there are no static settings anymore. It’s a lot easier ─ and more reliable ─ to do it via /etc/fstab.

I have a ramdisk and a HDD mounted on /run/media/username/ for months now and the permissions/ownership never changed. Only the ramdisk has a fstab entry if that makes a difference.

Yes, it does. :slight_smile:

But the HDD doesn’t and I don’t have to chmod/chown after every reboot. Am I missing something?

It can be done via systemd, but that’s like taking the engine out of your car in order to change the spark plugs, and it remains “apparently static” because nothing else has changed so far.

In a way, you could liken it to the /dev/sda, /dev/sdb designations for fixed drives. Those designations are assigned by the kernel at boot time based upon the order of detection, and it can appear stable, but there’s no guarantee that they will always point at the correct device. A single glitch at boot time could reverse their order, and I’ve seen it happen on more than one occasion. And that’s exactly why UUID and LABEL support was added to mount and fstab.

I really don’t see why we need to make things more difficult than they need to be. Adding a line for the filesystem to /etc/fstab is the easiest, simplest and most reliable approach.

Back again, currently working on @Aragorn’s solution and adding the UUID to a directory, will update shortly, thanks again to everybody.

Okay! So @Aragorn 's solution appears to have worked and everything is going as expected, so I will mark this as solved with their comment.

To summarize for the future visitors on their way here, I will summarize in this post here what I did. I will edit this if anybody feels I need to add or remove anything.

So, all of my freshly partitioned drives are already in ext4, which can be done easily using gparted. So this solution is for those who want permanent drives mounted to put stuff like their movies or games on it.

I used sudo mkdir /home/{username_here}/ChunkyHDD to make a directory. (I just did it under my username for simplicity sake)

I used Gparted to get the drive UUID and then added it to /etc/fstab/ with sudo nano /etc/fstab using @Aragorn 's solution post to add a new entry with the drive UUID added where they stated. And wrote the changes, then sudo reboot to start up again.

After that the drive is now statically mounted and can be used.

Going to do this for my other drive now too, though if I can ask a final question, would it be wise to do this for my formatted external SSD? I did partition that too, but given that I would be taking it out it might not be wise to give it a static mount right? It would have nofail in it to be fair so it wouldn’t stop it from booting, but is there an option suggested for removable external SSDs/HDDs?

Thanks again for the help though, this was exactly what I needed.

1 Like

With the nofail option you’re pretty safe, but I would perhaps also add the ssd option. It adds some minor performance tweaks. Also, add the noatime option for less wear. :wink:

Sorry for the “kind-of-offtopic” reply below but i had to point these out…

  1. That might be your personal opinion ofcourse, but it’s far from the truth :rofl:
    Because you know exactly what it does if you understood systemd mount units. :wink:
    It is also a lot easier to trouble shoot, because it won’t allow for a non-functioning system in case of errors. (One config file per mount point means elimination of errors wrt to the other mounts)
    Besides you can ask for the status of the mount points/units which will show all error messages related to it.
  2. The way you config makes the mount static or not, which is not possible with fstab.
    I guess you forgot or didn’t know that fstab is parsed and automatically converted to mount units by SystemD already.
    When it comes to being easier that has to do with old habits i’m sure, because it’s a lot more understandable eg. easier in mount units format :wink:

But i can understand why you think the way you do, because it is not how it used to be since SystemD…
I would advice you to get more familiar with systemd and i promise you that you will :heart: it once you get more familiar with all that it can do so far…

1 Like

I do like systemd ─ or at least, I do now, because that hasn’t always been the case ─ but I still think it’s easier for a newbie to learn how to do things via /etc/fstab, simply because it’s easier to set up, and they will then also become more familiar with the how and why behind mount options, mountpoints, et al, than if they are going to have to configure systemd mounts and then rely on systemd’s “automagic” rather than on understanding. :wink:

Uhmmm no.

  • Especially new users have a higher risk of making mistakes in fstab.
    Which could render a system non-functioning.
  • An error in a mount unit means only that mount will fail (With explanation of what was wrong)
  • Using fstab is actually relying on the “automagic” of systemd not the other way around :wink:
    The needed knowledge about mount points/options is the same for both because that is a sub-system on its own involving drivers etc if you go deep enough :wink:

The only part of “easier” i would agree upon is that it is less typing eg. shorter, but not easier for a human especially a new user to linux to understand