1. Overview

In this tutorial, we will investigate an error preventing us from writing to a directory despite our user account having group permissions. We will check the user account privileges, settings, directory permissions, ACLs, and hardware status.

2. Introduction to the Problem

We can reproduce the problem by performing the following steps:

  • create a directory
  • set the ownership of a directory to a given group
  • add our current user account to that group
  • try to create a file in the directory – an error occurs

Let’s go step by step through the problem. We are using the account user_a with the following user settings:

$ id
uid=1000(user_a) gid=1000(user_a) groups=1000(user_a),27(sudo),998(docker)
$ groups
user_a sudo docker

Next, we create a directory and set its ownership to users in the root and staff groups:

$ mkdir sampledir
$ sudo chown root:staff sampledir
[sudo] password for user_a:
$ ls -l
total 4
drwxrwxr-x 2 root staff 4096 Apr 1 10:44 sampledir

Then we add user_a to the staff group:

$ sudo usermod -a -G staff user_a

Finally, we continue by attempting to create a file by using the touch command, which in turn will throw an error:

$ touch sampledir/samplefile.txt
touch: cannot touch 'sampledir/samplefile.txt': Permission denied

That error shouldn’t have occurred as we seem to have done everything necessary. In the next section, we will try to investigate what may have caused the error.

3. Solutions

There are several ways that we can try to deal with the problem above. Let’s try some of them.

3.1. Check User Privileges and Settings

After we modify any groups like adding user_a to the staff group, we need to ensure the console loads these changes:

$ id
uid=1000(user_a) gid=1000(user_a) groups=1000(user_a),27(sudo),998(docker)
$ groups
user_a sudo docker

As we can see above, the console that we’re using hasn’t been updated with our modifications; user_a is still not in the staff group.

We can enforce the changes by opening a new console or running su – user_a in the running console:

$ su - user_a
Password:
$ id
uid=1000(user_a) gid=1000(user_a) groups=1000(user_a),27(sudo),50(staff),998(docker)
$ groups
user_a sudo staff docker
$ touch sampledir/samplefile.txt
$ ls -l sampledir
total 0
-rw-rw-r-- 1 user_a user_a 0 Apr 1 11:36 samplefile.txt

At this point, we should be able to make changes to the directory. In case of failure, let’s continue to the next section.

3.2. Check Directory ACLs

This case might be uncommon, but we may need to check the ACLs (Access Control Lists) of the directory. For example, it could have been created with a default ACL for certain users and/or groups.

If we see a plus (+) sign at the end of the directory permissions, it indicates the directory has special access rules:

$ ls -l
total 4
drwxr-xr-x+ 2 root staff 4096 Apr 1 11:55 sampledir

Let’s check the directory ACLs with the getfacl command:

$ getfacl sampledir
# file: sampledir
# owner: root
# group: staff
user::rwx
user:user_a:r-x
group::r-x
mask::r-x
other::r-x

The line user:user_a:r-x shows that user_a only has r-x access to the sampledir directory.

Let’s modify the rules with the setfacl command and then verify them:

$ sudo setfacl -m u:user_a:rwx ./sampledir
$ getfacl sampledir
# file: sampledir
# owner: root
# group: staff
user::rwx
user:user_a:rwx
group::r-x
mask::rwx
other::r-x

At this point, we have successfully changed the ACLs, and we’re supposed to be able to make changes to that directory with user_a:

$ touch sampledir/samplefile.txt
$ ls sampledir/ -l
total 0
-rw-r--r-- 1 user_a user_a 0 Apr 1 12:41 samplefile.txt

If we still cannot make any changes to the directory, let’s turn to the next section.

3.3. Re-Login or Restart the System

We can re-login or restart the system to ensure the system loads all the changes that we made.

After logging in again and restarting, we can try to make some changes to the directory. If we’re getting the same error, we have one more option.

3.4. Check the Partition or Hardware

A faulty hard disk may throw an error when we try to use it, or a partition with incorrect mount options, for example:

$ mkdir test
mkdir: cannot create directory test: Read-only file system
$ touch test
touch: cannot create file test: Read-only file system

We can try to fix the issue by ensuring the mount options for the partition in /etc/fstab are correct and then remounting the partition.

To remount the partition, first, let’s ensure the partition is mounted by running the mount command:

$ mount
...
/dev/sda3 on / type ext4 (rw,relatime,errors=remount-ro)
...

Then remount the partition:

$ sudo mount -o remount /

If at this point, we’re still getting errors when we try to make changes to the directory, we might need to explore the possibility of hardware problems.

4. Conclusion

In this article, we investigated the error preventing us from writing to a directory despite having group permission by checking the user account privileges and settings, directory permissions, ACLs, and hardware status.

Comments are closed on this article!