I have a hard disk partition with no mount point and freshly formatted at ext4 file system. I want to store my own files there. But trying to create anything there tells me that permission is denied. I deleted that partition and recreated it only to experience the exact same thing. How can I make that partition usable without any limitations? I have no idea why this is even happening in the first place... The chown command didn't work, without "sudo" it returns permission denied which is hilarious (that is why I am using that command in the first place) and with "sudo" literally nothing happens.
Addressing your questions:
The way I understand it, the lubuntu file manager doesn't let one use any partition that doesn't have a mount point unless one has root access.
I never would have had to change permission to a brand new-formatted hard disk as if it is owned by someone else.
- It's not about Lubuntu. This works like this in Ubuntu and at least several other Linux distributions.
- This is not about the file manager. Command line access also works like this.
- It's not about the disk or the partitions. It's about the folders. (And later on, the contents of those folders too, like files and subdirectories in them. But that comes later.)
Do an experiment:
sudo mkdir /mnt/test_dir_1
or, to demonstrate that it's not related to
/mnt at all, another one directly in
sudo mkdir /test_dir_2
- As you have seen, sudo was needed to create these directories.
- Nothing is mounted, nothing is about disks; these are just normal directories.
- Now go ahead and try to copy anything into these directories.
- Errrr. Permission denied. You need
sudoto change the contents of these directories at all.
- Errrr. Permission denied. You need
Why is that? Because you have created them with sudo. And you had to use sudo because they are outside your
/home/<YOURUSERNAME> directory. You get to freely move things around and change files only in your user's own directory. Elsewhere you get restricted very soon.
/test_dir_2 are outside of your home directory, and therefore restricted areas for your user. You need sudo to put or modify anything in there. In most of the places you get at least a read permission without sudo: listing contents and opening files are allowed. But changing anything requires sudo. This is standard Linux stuff. Later on we will get to why it works like that.
The funny thing is, without root access I couldn't even modify the fstab file.
Now you see why. the
/etc/fstab file is in
/etc, a highly restricted system folder.
Now comes a different experiment. Follow along:
# This creates an empty text file: sudo touch /mnt/test_dir_1/test.txt # This lists the contents and shows you the new file in there: ls -l /mnt/test_dir_1
Now when you mount a partition, then things can get a bit (more) confusing.
Mounting a partition to
/mnt/test_dir_1 somehow replaces that directory with another one, one that represents the partition.
test.txt will disappear from
/mnt/test_dir_1, while the partition is mounted there.
When you unmount the partition with the
umount command, the original contents "return", and you get to see
test.txt in there again.
when I did use the
sudo, nothing happened, neither did it fix the problem. It just accepted the command but didn't react to it in any way.
chown manages to run without any issues, it does not return any message.
The reason you might have not perceived any change afterwards, could be that all the contents in there were already impacted by the fact that you have previously used the file manager as administrator, to create and modify them. Now all that content belongs to
root, not you. Permission is still denied to your user, you still need sudo to modify them.
sudo chown -R YOURUSERNAME:YOURUSERNAME /mnt/my_stuff
-R part, for recursive) should fix that.
By now, you may notice that it makes an important difference whether the partition is mounted on this directory or not, when you issue this command.
For a good measure, in this specific case, you can run it in both cases. Once when the partition is not mounted, and once when it is. That should do it.
How can you form an idea about ownership and permissions?
ls -l command to list stuff in a directory. That shows you.
Let's use our previous example where we used
sudo touch to create a text file.
ls -l /mnt/test_dir_1 -rw-r--r-- 1 root root 0 Feb 14 16:26 test.txt
This line shows you that the
test.txt file is owned by the
root user belonging in the
# This will change the ownership of all contents, giving them to you. sudo chown -R YOURUSERNAME:YOURUSERNAME /mnt/test_dir_1 ls -l /mnt/test_dir_1 -rw-r--r-- 1 YOURUSERNAME YOURUSERNAME 0 Feb 14 16:26 test.txt
But why does it all have to work that way?
I believe it's for system security. When you log in, you end up as your regular non-sudo user.
Any command that is issued, and any script that is being run, is being done so as your user. If you want to do anything that would impact the system itself, you have to authenticate first, with your password, triggered by
sudo before commands.
Thing is, scripts can sometimes run without your knowledge. Potentially malicious scripts might find their way onto the computer, might run in the background, and try to change the system. But thanks to this system of restrictions nearly everywhere, an evil script will not get far compromising the system. Because everything is protected by this system of ownership and permissions.
A theoretical demonstration for this kind of defense could be a case called "arbitrary code execution" vulnerability. It can happen to various programs that process data that is originating from outside of your computer; like content originating from the internet.
Video codecs can sometimes suffer from this kind of vulnerablity. When you watch a maliciously prepared video, the video stream may contain a "booby-trap" for the video-parser codec that the video-player app uses. That can trick the codec/player into a so-called "arbitrary code execution" state, where a "script" is being spawned and being run on your system.
Then it's important that the video player app is being run by your user. That way the spawned and executed malicious code will also be run on behalf of your user: Without having the sudo password, the script will end up failing to meet its goal.
A long-term defense of course is to keep updating packages on the system. As soon as such vulnerabilities are identified in software, an update is being released for them, and the new, improved version replaces the old vulnerable one.
But the system of controlled ownership and permissions nicely held your system together even before installing the security update.
But it seems inconvenient
You could say, like tens of thousands of novice Linux users before you: "Now I will be smart, and run everything as root / administrator, so I will never have to worry about passwords."
- It will compromise the security of the system, from day one (I have added an example, just above).
- Directory and file ownerships may end up in a sorry mess that will need extra work to sort out.
Don't get tempted; instead, recognize that this system is in place for your long-term enjoyment of your operating system. Get used to it.
What you can do to make your life easier is choosing a password that is easy and quick to type. When it becomes muscle memory, you will even draw reassurance from it.
There seem to be confusion about mounting.
After your installation is complete, you don't need to keep going back to a disk / or partition manager program any more.
You should be able to mount partitions at any time using just the terminal. For example something like this:
sudo mkdir /mnt/my_stuff sudo chown YOURUSERNAME:YOURUSERNAME /mnt/my_stuff
sudo mount /dev/sdaX /mnt/my_stuff
Here you mount the example partition
/dev/sdaX to the
/mnt/my_stuff directory. (But you have to create this target directory first, and change its ownership to yourself (with
To determine the exact partition identifier, you can use the command:
sudo lsblk -e 7
After you have done this, you cannot say it has no mount point. Now it's mounted. Now it has a "mount point".
What you probably meant was that there was no assigned mount point at installation time, but that's not very important. That just means, that if you want this to survive a reboot, you will have to add an entry to
/etc/fstab manually. That makes the mounting automatic on each boot. Look here for a well-contained small example. Then search the net for the term "etc/fstab examples explained" or something. Also read about the mount options.
Now you are well-prepared and patient enough to deal with the info in them.