A folder created in the wrong location or with overly permissive rights often leads to problems later. The mkdir command is sufficient to start, but it does not replace the checking of ownership, group, and permissions.
For a personal directory, create it in your user folder. For a shared directory or one used by a service, first identify the account that needs to write to it. A chmod 777 often masks a real ownership issue and allows all local accounts to modify the content.
Create the folder in the right location
From the current folder, the following command creates a single directory:
mkdir backups
With an absolute path, you know precisely where the folder will be created. Add -p if the parent folders may be missing:
mkdir -p ~/projects/test-site/logs
Without -p, mkdir stops if ~/projects/test-site does not exist. This option also avoids an error when the last folder is already present. It does not transform an incorrect path into a correct path: check it with pwd before launching the command.
To prepare a space that should belong to your account, stay in your personal directory. This will avoid sudo, so a folder created by root that your user can no longer populate:
mkdir -p ~/archives/2026
stat -c '%A %U:%G %n' ~/archives ~/archives/2026
Choose appropriate rights for use
A folder requires the x right to be traversed. In a directory, r allows listing names and w allows adding, renaming, or deleting entries. The rights actually applied also depend on your umask.
For a private folder, create it with an explicit mode:
mkdir -m 700 ~/private-archives
stat -c '%A %a %U:%G %n' ~/private-archives
The mode 700 gives access to the owner and closes the folder to other users. For a directory where a working group needs read and write access, prefer a known group and the mode 2770:
sudo install -d -o alice -g web-team -m 2770 /srv/web-team
stat -c '%A %a %U:%G %n' /srv/web-team
The 2 at the beginning activates the setgid bit of the folder. New files and subdirectories will then inherit the web-team group. This solution prevents granting write access to all accounts on the server. Verify that the expected members are indeed in this group with id username.
mkdir -m 777 creates a directory writable by everyone, and the umask can still reduce this mode. Do not use it to fix a Permission denied. Instead, read the full path, its owner, and the rights of each parent folder:
namei -l /srv/web-team
ls -ld /srv /srv/web-team
id
Check before handing over the folder to a service
A service running under www-data, postgres, or a dedicated account does not necessarily see the same rights as your session. Check its user before changing anything. For systemd, this command gives the accounts configured by the unit:
systemctl show my-service
-p User -p Group -p DynamicUser
Then create the folder with the expected owner, and test a file from this account. On a test machine:
sudo install -d -o www-data -g www-data -m 750 /var/lib/my-service
sudo -u www-data touch /var/lib/my-service/test-write
ls -l /var/lib/my-service/test-write
sudo rm /var/lib/my-service/test-write
This check tells you if the service account can actually write. If it fails, do not add permissions randomly. First, check the owner, group, any possible ACLs with getfacl, and the rights of the parent directories.
- Use
mkdir -pfor a path whose parents may be missing. - Use
statorls -ldimmediately after creation. - For a shared folder, set the owner, group, and mode before starting the service.
- Reserve
chmodfor targeted correction, after identifying the blocked account.
The guide on setfacl under Linux helps when a single user needs additional access. If you need to modify permissions in an existing tree, use the procedure dedicated to recursive chmod: changing all files and directories with the same mode easily breaks the execution rights of the directories.
The man page mkdir(1) details the options, and mkdir(2) explains the effect of umask and group inheritance. Keep these two points in mind before creating a folder used by a service.
