Owner of a Mounted Partition

1. Introduction

When using the mount command to attach filesystems and partitions at a given location, it may not always be clear who the owner of this new mount point is going to be. As a result, we might not have the proper permissions.

In this tutorial, we’ll talk about mount point ownership and how to modify it. First, we follow the usual mount process and establish the way owners change. Next, we perform partition mounting as a regular user in different ways. After that, we turn to a workaround for particular protocols. Then, we explore a related technology used in many graphical user interfaces. Finally, we describe a relatively simple but dangerous way to change the owner of a mount point and its contents.

We tested the code in this tutorial on Debian 11 (Bullseye) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments.

2. Partition Mount Process and Permissions

To begin with, let’s create a simple non-removable partition mount.

First, we create a directory as user baeldung with the mkdir command and its –parents flag:

$ whoami
baeldung
$ mkdir --parents /home/baeldung/point

After verifying the current user with whoami, we create the /home/baeldung/point directory.

Next, let’s check the permissions of the new directory with ls -ld:

$ ls -ld /home/baeldung/point
drwxr-xr-x 2 baeldung baeldung 4096 Apr 10 00:01 /home/baeldung/point

Notably, baeldung owns and has full control over the path.

At this point, we can attempt to mount /dev/sda1 without any options as the same user:

$ whoami
baeldung
$ mount /dev/sda1 /home/baeldung/point
mount: /home/baeldung/point: must be superuser to use mount.

As expected, we get a warning about not being a superuser. Thus, we do it as root instead:

# whoami
root
# mount /dev/sda1 /home/baeldung/point

Now, let’s compare the current with the previous permissions:

$ ls -ld /home/baeldung/point
drwxr-xr-x 2 root root 4096 Apr 2 20:22 /home/baeldung/point

Notably, all metadata of the mount directory has changed. Critically, the new owner is root. So, how can we preserve ownership during the mount?

3. Using mount as Non-superuser for a Partition

When it comes to partition mounting as a regular user, we have many options depending on the circumstances.

3.1. Using mount and /etc/fstab

Until recently, adding user as an option to an /etc/fstab entry enabled us to mount as a regular user:

$ cat /etc/fstab
# <file system>  <mount point>         <type>  <options>  <dump>  <pass>
  /dev/sda1      /home/baeldung/point  ext4    user       0       0     
[...]

Since the mount command always reads /etc/fstab for non-superusers, mounting with it should honor these options as long as we use only the file system or mount point:

$ whoami
baeldung
$ mount /dev/sda1

However, even such a mount doesn’t end up with the expected owner:

$ ls -ld /home/baeldung/point
drwxr-xr-x 2 root root 4096 Apr 2 20:22 /home/baeldung/point

Further, this mechanism may not always work, as mount is entirely disabled within certain non-superuser contexts under the latest version of some Linux distributions like Debian and Ubuntu.

3.2. Using sudo

Of course, we can use sudo for the mount:

$ sudo mount /dev/sda1 /home/baeldung/point

Again, the resulting permissions over the mount point would be the same that we saw earlier:

$ ls -ld /home/baeldung/point
drwxr-xr-x 2 root root 4096 Apr 2 20:22 /home/baeldung/point

Thus, this also isn’t viable for our needs.

3.3. pmount and udisks

To mount removable drives as a non-superuser, we can leverage additional tools:

• pmount
• udisks2

Let’s install them with apt:

$ apt-get install pmount udisks2

Now, we should be able to simply issue a pmount or udisksctl command for a removable storage drive as identified by a tool like fdisk:

$ pmount /dev/sdb1
$ udisksctl mount --block-device /dev/sdb1

Here, we assume /dev/sdb is a USB block device. Also, since that’s how both of these tools work, the mount point will be in the /media directory.

Needless to say, the ownership remains with root, so this solution doesn’t help us either. Actually, for most filesystems like FAT32, ext4 and XFS, and similar, unless we modify the ownership explicitly after the fact, the owner will be the mounting user, and that can only be a superuser when it comes to partitions.

4. SAMBA and mount.cifs Ownership Options

When using SAMBA, we can work around the limitations of partition mounting by using several mount options:

• uid – set the owner of all data
• forceuid – force the uid setting
• gid – set the owning group of all data
• forcegid – force the gid setting

Let’s see a basic example:

$ mount -o uid=baeldung,forceuid,gid=baeldung,forcegid,rw //smbsvr/smbShare /home/baeldung/point
$ ls -ld /home/baeldung/point
drwxr-xr-x 2 baeldung baeldung 4096 Apr 10 00:01 /home/baeldung

The ownership is as expected. In addition, we can employ umask settings. While NFS also supports user ID mapping, it uses a separate daemon.

Now, let’s see a method that implicitly leverages similar options by default.

5. Using Filesystems in USErspace (FUSE)

Some filesystems have userland implementations.

For example, SSHFS and GVFS employ FUSE, which doesn’t require superuser rights. In fact, tools like gio allow user mounts out of the box.

Most default FUSE mounts end up with the expected permissions, i.e., the owning and mounting user being the same:

$ whoami
baeldung
$ gio mount smb://192.168.6.66/smbShare
$ ls -ld /run/user/1001/gvfs/smbShare
drwxr-xr-x 2 baeldung baeldung 4096 Apr 10 00:01 /run/user/1001/gvfs/smbShare

Not all filesystems and protocols support user changes. Here, we use the SAMBA protocol, which does.

In essence, the above is the default way FUSE is meant to work. In fact, even root might be unable to access another user’s mount point unless allow_other or allow_root are added to /etc/fuse.conf.

6. Changing the Owner After Mounting

Importantly, global recursive changes to the owner of all data on a filesystem can be extremely damaging, especially for system partitions. That said, we can easily do that after we perform the mount.

Let’s mount with sudo first, tracking the permissions as we did earlier:

$ whoami
baeldung
$ ls -ld /home/baeldung/point
drwxr-xr-x 2 baeldung baeldung 4096 Apr 10 00:01 /home/baeldung/point
$ sudo mount /dev/sda1 /home/baeldung/point
$ ls -ld /home/baeldung/point
drwxr-xr-x 2 root root 4096 Apr 2 20:22 /home/baeldung/point

We can see that the permissions evolve like before. So, let’s try and influence them now:

$ sudo chown -R baeldung:baeldung /home/baeldung/point
$ ls -ld /home/baeldung/point
drwxr-xr-x 2 baeldung baeldung 4096 Apr 2 23:33 /home/baeldung/point

At this point, we use a sudo-elevated chown command to change the ownership of all data on the filesystem that root has control over, as well as the mount point itself. Again, this can be highly destructive.

7. Summary

In this article, we discussed changing the owner of a mount point and location.

In conclusion, while we can’t usually influence the ownership when mounting regular partitions, especially as a regular user, we do have options when it comes to permissions over mounts.