A Practical Guide to File Permissions in elementary OS

File permissions are the rules that decide who can open, change, run or remove a file. In elementary OS, these rules protect personal data, prevent accidental system changes and allow several accounts to use the same computer safely. They apply to documents in Home, application files, scripts, removable drives and directories shared across a network.

Most everyday tasks are handled through Files, elementary OS’s graphical file manager. You can create folders, move documents and inspect basic properties without touching the terminal. When a permission problem appears, however, a few Linux concepts—owner, group, read, write and execute—make the cause much easier to understand.

This matters for common situations in Australia, from storing tax records before the end of the financial year to sharing coursework between family members in Sydney or Melbourne. It is also useful when an NBN-connected home server, a USB drive formatted on another computer or a work folder used by several people behaves differently from your personal files.

How Linux Assigns Ownership

Every file and directory in elementary OS has an owner and an associated group. The owner is usually the account that created the item. The group is a collection of accounts that may receive shared access. A file also has permission rules for three categories: the owner, members of the group and everyone else on the system.

You can inspect ownership from the terminal with:

ls -l ~/Documents

A typical result may look like this:

-rw-r--r-- 1 alex users 2480 Mar 12 09:30 budget.txt

The first character indicates the item type. A hyphen means a regular file, while d means a directory. The next nine characters are permission bits, grouped into owner, group and other. In this example, alex owns the file and users is its group. The file is readable and writable by Alex, while everyone else can read it but cannot edit it.

The account that owns a file is not necessarily the person physically sitting at the computer. If a file was copied using sudo, extracted by an administrator or created by a service, it may belong to root. That can make a document appear in Files but refuse to open, rename or delete normally. Ownership should be corrected carefully rather than solved by running every file operation as an administrator.

To see your current username and groups, use:

whoami
groups

The first command prints your account name. The second shows groups such as sudo, audio, video or other local groups. Group membership is especially useful on a shared desktop, a home server or a workstation used by a household in Brisbane.

Reading Permission Bits Without Guesswork

The three basic permissions are read, write and execute. Read allows a file’s contents to be viewed. Write permits changes or deletion in some contexts. Execute allows a program or script to run. For a directory, these meanings are slightly different: read lists its contents, write creates or removes entries, and execute allows access to items inside it.

A text document might have 644 permissions. The first digit, 6, gives the owner read and write access; the second and third digits, 4 and 4, give the group and other users read access. A private document commonly uses 600, allowing only its owner to read and modify it.

Executable files often use 755. The owner can read, write and run the file, while the group and other users can read and run it. A directory such as a personal scripts folder may also use 755, because users need execute permission to enter it. A shared directory may instead use 775, giving the owner and group full access while withholding write access from everyone else.

The numeric values come from adding three permissions:

read    4
write   2
execute 1

This command gives a file private read and write access:

chmod 600 ~/Documents/private-notes.txt

A safer general approach is to change only the permission that needs changing. For example:

chmod u+x ~/bin/backup.sh
chmod g+w ~/Shared/project.txt
chmod o-r ~/Documents/record.pdf

Here, u means owner, g group and o other. The plus sign adds a permission and the minus sign removes one. This style is often easier to audit than replacing all permissions with a number, particularly when managing work files or scanned Australian Privacy Act records.

Changing Ownership and Group Access

The chown command changes ownership. It normally requires administrator privileges when the current account does not own the item:

sudo chown alex:users ~/Shared/project.txt

This changes the owner to alex and the group to users. Replace those names with the actual account and group on the computer. Before making the change, check them with whoami and groups. A mistyped account name can produce an error, while a careless recursive change can affect far more files than intended.

For a directory and everything inside it, the recursive form is:

sudo chown -R alex:users ~/Shared/project

Use -R only when the entire tree should have the same owner and group. Applying it to /, /usr, /etc or another system directory can damage the operating system. The same caution applies to broad commands such as sudo chmod -R 777, which removes meaningful protection and gives every local user permission to modify the affected content.

The chgrp command changes only the group:

chgrp projectteam ~/Shared/project.txt

If the group does not exist, an administrator can create one with sudo groupadd projectteam, then add an account with sudo usermod -aG projectteam alex. The user normally needs to sign out and sign in again before the new group membership is active. A household might use a group for shared photos, while a small design studio in Melbourne could use one for project assets.

Directories need a little planning. To let a group create and edit files, the directory needs group write and execute permissions:

sudo chown -R alex:projectteam ~/Shared/project
chmod 2775 ~/Shared/project

The leading 2 sets the setgid bit on the directory. New files created inside inherit the directory’s group, reducing ownership confusion. File creation permissions still depend on the creator’s umask, so this is useful but not a complete permission policy.

Managing Permissions in Files

Files in your home folder usually work without manual configuration. In Files, right-click an item and choose Properties to see its location, size and other information. The exact graphical controls available can vary by elementary OS release and file type, so the terminal remains the most reliable way to inspect or adjust ownership and mode bits.

A frequent problem occurs when an archive or installer places files in a location owned by root. You may see a padlock icon or receive an “access denied” message when trying to edit or delete something under your Home folder. First inspect the item:

ls -ld ~/Downloads/suspect-folder
ls -l ~/Downloads/suspect-folder

If the folder should belong to you, correct that specific folder:

sudo chown -R "$USER":"$(id -gn)" ~/Downloads/suspect-folder

The variables use your current account and primary group, making the command more portable. Avoid changing ownership simply because a file is protected. System files are meant to be owned by root, and altering them may make updates or boot processes unsafe.

Scripts downloaded from a website are usually created without execute permission. Rather than making every file executable, grant it only to a script you trust:

chmod u+x ~/Downloads/report-script.sh

Run it from its directory with:

./report-script.sh

If the script came from an unknown source, inspect its contents first. Execute permission does not make a script trustworthy; it merely allows the system to run commands inside it. This distinction is important when downloading utilities over café Wi-Fi in Perth or from a public library network.

Files copied from Windows or macOS can show unexpected behaviour. A USB disk formatted as exFAT or NTFS may not support ordinary Linux ownership and permission bits in the same way as an ext4 filesystem. The mount options then determine the apparent owner and access mode. For a portable drive used between an elementary OS laptop and a Windows PC, this is normal; for a Linux-only drive, ext4 generally provides more complete permission support.

Troubleshooting Access Problems Safely

When an application says it cannot save a file, identify the exact path first. Check the file’s permissions, then check every parent directory:

namei -l ~/Documents/work/report.odt

This displays the permissions along the path. You may own the file but lack execute permission on one parent directory, or you may have permission to read a directory but not to write inside it. If the file is on a mounted drive, also check how the drive was mounted and whether it is read-only.

A locked file does not always indicate a Unix permission problem. Flatpak applications, which are common in the elementary OS ecosystem, use sandbox permissions as an additional security layer. An application may have normal file ownership access and still be unable to see a folder because the sandbox has not been granted access. In that case, inspect the application’s permissions in its settings or use a suitable portal rather than changing the file to 777.

The same applies to network shares. A Samba share, NAS device or server may have its own account and access rules. Permission changes made locally may not alter the server’s policy. If a shared folder on a home NAS connected through an NBN router is read-only, check the NAS account, share configuration and mount options as well as local Linux permissions.

A useful diagnostic sequence is:

ls -ld /path/to/item
ls -l /path/to/item
id
mount | grep -E 'Documents|media|mnt'

Read the output before using sudo. If you need to repair a personal folder, target that folder directly. Keep backups before changing permissions in a work directory, especially when it contains ATO paperwork, client records or university assignments. The Australian Privacy Principles also make sensible access controls important for organisations handling personal information, even though a single home computer does not need a complicated compliance system.

The safest permission setup is usually the least powerful one that supports the task. Keep private records at 600 where practical, use group access for genuinely shared folders, avoid recursive commands unless you have checked the path, and reserve administrator privileges for operations that truly require them.

Understanding ownership and access modes turns many elementary OS file errors into straightforward maintenance. The key is to remember that owner, group, directory access and application sandbox rules can all affect the same file. Check those layers in order, change the smallest possible target, and protect the principle that only the people and programs that need access should receive it.