Mount Permissions and Remounting a Filesystem as Writable

1. Introduction

When mounting a filesystem in a Linux environment, permissions are a very important factor. Specifically, read-only and read-and-write access configurations determine how we interact with the data. Sometimes, after a filesystem is already mounted, we may need to change this setting globally.

In this tutorial, we discuss filesystem writability, as well as when, why, and how we change it. First, we talk about mount permissions. After that, we look at parallel mounts of the same filesystem. Finally, we deal with remounting.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.

2. Mount Readability and Writability

When it comes to mounting a whole filesystem, we usually have two choices:

• ro: read-only
• rw: read-write

Importantly, let’s first understand the output of the mount command to have a way of confirming our mounts:

$ mount
[...]
<DEVPATH> on <MNTPATH> type <FSTYPE> (rw,[...])

Notably, we see several columns:

• <DEVPATH>: block device path
• on <MNTPATH>: path of mount
• type <FSTYPE>: filesystem type
• (rw,[…]): mount options

Although there are many, one of these mount options tells us the mount permissions mode for the device at the given path.

Let’s explore this concept with some examples.

2.1. Read-write Mount (Default)

First, we mount the /dev/sdx1 device at /mnt/point:

$ mount /dev/sdx1 /mnt/point

Next, we check the output of mount:

$ mount
[...]
/dev/sdx1 on /mnt/point type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)

So, our device is in rw read-write mode. Let’s verify this:

$ touch /mnt/point/file-rw
$ echo $?
0

In this case, we create a new file at the mount path via touch and verify the command ran without problems by checking the $? special variable.

To reset, we umount from /mnt/point:

$ umount /mnt/point

At this point, /dev/sdx1 isn’t mounted.

2.2. Read-only Mount

Before we continue, let’s use mountpoint to ensure we don’t have a mount at /mnt/point:

$ mountpoint /mnt/point
/mnt/point is not a mountpoint

So, we can mount /dev/sdx1 at /mnt/point with some –options:

$ mount /dev/sdx1 /mnt/point --options ro

In particular, we set the ro read-only mode as confirmed by the output of mount:

$ mount 
[...]
/dev/sdx1 on /mnt/point type xfs (ro,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)

Naturally, we should now be unable to write new files:

$ touch /mnt/point/file-ro
touch: cannot touch '/mnt/point/file-ro': Read-only file system
$ echo $?
1

As expected, we get both an error and an appropriate exit code when attempting writes.

Of course, reading should be fine:

$ ls /mnt/point
file-rw
$ cat /mnt/point/file-rw
$

In this instance, both the ls and cat commands work fine and show the file we already created.

Again, we umount our device.

Notably, these options aren’t affected by the mount owner.

3. Parallel Mounts of the Same Filesystem

If we mount a filesystem while we already have it mounted at a different location on the same system, its permissions can affect the new mount as well.

So, let’s explore and understand how concurrent mounts behave.

3.1. After One Read-write Mount

First, let’s mount a filesystem at a given location:

$ mount /dev/sdx1 /mnt/point-rw --options rw

For clarity, this command explicitly indicates the rw permissions mode.

Now, let’s try to mount at another path without unmounting /mnt/point-rw:

$ mount /dev/sdx1 /mnt/point --options rw

At this point, we have two rw mounts of /dev/sdx1.

However, let’s see what happens when we attempt a ro mount:

$ mount /dev/sdx1 /mnt/point-ro --options ro
mount: /mnt/point-ro: /dev/sdx1 already mounted on /mnt/point-rw.
       dmesg(1) may have more information after failed mount system call.

Critically, we can’t perform this operation because /dev/sdx1 is already exposed for reading and writing at a different location, so the read-only limitation can’t be imposed for the new mount at /mnt/point-ro. This is in contrast to the usual permissions mechanism, which enables different locations to have separate permissions.

To reset, let’s umount the /dev/sdx1 device from all paths:

$ umount /dev/sdx1
$ umount /dev/sdx1

Actually, this situation is more akin to having symbolic links to the same path since symbolic link permissions aren’t taken into account. The same is true for the next.

3.2. After One Read-only Mount

On the other hand, let’s see what happens when we first mount a system read-only:

$ mount /dev/sdx1 /mnt/point-ro --options ro

At this point, /dev/sdx1 is available at /mnt/point-ro for ro read-only operations.

Next, we attempt a parallel read-only mount:

$ mount /dev/sdx1 /mnt/point --options ro

No problems so far.

Now, let’s try to attach /dev/sdx1 at another location with rw permissions:

$ mount /dev/sdx1 /mnt/point-rw --options rw
mount: /mnt/point-rw: WARNING: source write-protected, mounted read-only.

The system automatically detects that the source filesystem is already mounted read-only, so it doesn’t permit us to change the original permissions even for a new mount.

In other words, we get the same behavior in both situations: once mounted with a given permissions set, we can modify it without unmounting first.

4. Remounting

To change mount parameters, we often need to remount the whole filesystem. However, depending on the circumstances, this might be non-trivial.

Critically, we can mount the same filesystem at different mount points, but we can also remount a filesystem at the same mount point. Of course, to do that, the system needs to unmount it beforehand.

For example, let’s first mount a filesystem as read-only:

$ mount /dev/sdx1 /mnt/point --options ro

Now, we can remount this ro read-only filesystem as rw read-write:

$ mount /dev/sdx1 /mnt/point --options remount,rw

Yet, this can present challenges when dealing with live or otherwise in-use filesystems.

In fact, tools like fsck have specific flags to deal with such situations. For example, the -n flag employs read-only mode when performing the filesystem checks.

Actually, remounting a live read-only filesystem as read-write is usually less of a problem than trying to remount a live read-write filesystem as read-only.

5. Summary

In this article, we talked about mounting, parallel mounts, and remounts in terms of the permissions the attached location has.

In conclusion, knowing that a given filesystem mount is affected by previous mounts as well as the conditions for remounts can be invaluable when dealing with a complex system setup.