I'm trying to change the default permissions assigned to files when created by the docker daemon by changing the default umask. The docker daemon service runs as root and creates the files with umask of root. I tried changing the umask by adding a command to /etc/init.d/docker and also passed the desired umask(000) as an option to start-stop-daemon but none of them seem to be working. How can I change the default permissions assigned to files created by docker daemon? Edit: I am trying to set the default permissions for files and folders created by the docker daemon on the host and not within a container. For instance, if a folder on host machine, mapped within a container, doesn't exist, docker automatically creates the folders and assigns permissions based on default umask(which is that of root).

In [_Classic Shell Scripting_ from O'Reilly](https://learning.oreilly.com/library/view/classic-shell-scripting/0596005954/) , Arnold Robbins and Nelson H.F. Beebe write the follwing example: >

> $ umask
> 023
> $ rm -f foo
> $ cp /bin/pwd foo
> $ ls -l /bin/pwd foo
> -rwxr-xr-x   1 root    root     10428 2001-07-23 10:23 /bin/pwd
> -rwxr-xr--   1 jones   devel    10428 2002-09-21 16:37 foo
>

> The resulting permission string rwxr-xr-- reflects the loss of privileges: group lost write access, and other lost write and execute access. Now, the 023 output at the beginning, tells me that in the current shell, _newly created files_ would have w access removed for g and wx removed for o, so while I understand that "other lost execute access", I don't get "group lost write access" nor "other lost write access", as neither of them had it in the first place. Do you think it's just an inaccuracy of the wording of that comment, or am I missing something? Furthermore, I've tried that on my system, and the result puzzles me a bit more:

$ umask 
0023
$ cp /bin/pwd ~/foo
$ ls -l /bin/pwd ~/foo 
-rwxr-xr-x 1 root   root   35072 Jan 18 19:17 /bin/pwd*
-rw-r--r-- 1 myself myself 35072 Feb  1 12:54 /home/myself/foo

Now, the output of 0023 should mean removal of w for g and wx for o (of which only x for o was actually present, so it's the only one removed in this case), but instead it looks like the x permission has been removed too for both u and g. Why is that? Where can I find all the rules that determine what happens, as far as permissions go, when I create and when I copy a file?

[user@localhost ~]$ umask
027
$ sudo su -
[root@localhost ~]# umask
0027

[root@localhost ~]# exit
[user@localhost ~]$ umask 0022
[user@localhost ~]$ umask
0022

$ sudo su -
[root@localhost ~]# umask
0022

I thought su - is supposed to clear environment variables and start a login shell, yet umask is not cleared. Why?

How do I make SCP respect umask ? I've tried adding this Subsystem sftp internal-sftp -u 0002 in /etc/ssh/sshd_config and session optional pam_umask.so umask=0002 in /etc/pam.d/sshd Any other things to try? each time scp creates the file as 644 instead of 664 as the umask would suggest

I have an nfs mount created on a Linux server, and a process that is creating directories and files dynamically as it runs. As expected, the directories have an owner:group of nobody:nogroup. The issue is that the default umask is yielding permissions like this: drwxr-x--- 2 nobody nogroup 4096 Sep 6 20:17 /shares/dra/rman/ORCL/mtd_inputs_2024-08-27/scott/datafile That directory is created by a client on another Linux server, by an Oracle RMAN job. It later invokes an Oracle DDL command to create an Oracle Directory object, that allows Oracle to access that Linux directory. I am getting errors when the RMAN tries to access directories in that hierarchy. When googled, those errors has some hits on Oracle support, including this note That note leads me to think that perhaps the Oracle Directory object can't access the directories since there is no "world" access. The directories are created dynamically during the RMAN job so I can't change permissions in advance. The task is a long-running one, and right toward the end, it creates a new directory and apparently a child process attempts to access it, and I'm pretty sure it is due to the directory permissions. Is there a way to change the default umask to yield directory permissions to be 777 for the nobody user ID? I can't change it on the client user ID. The entry for nobody in /etc/password shows a non-existent home directory and /usr/sbin/nologin shell:

bash
Prompt> grep nobody /etc/passwd
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

Versions:

bash
Prompt> uname -a
Linux project01 4.19.0-26-amd64 #1 SMP Debian 4.19.304-1 (2024-01-09) x86_64 GNU/Linux
Prompt> cat /etc/debian_version
10.13

The client is running Oracle Linux Server release 7.9. Update: My entry for the server in question in /etc/exports looks like this:

bash
Prompt> grep /shares/dra /etc/exports
/shares/dra exampledev01(rw,sync,no_subtree_check,all_squash,anonuid=65534,anongid=65534)

I'm trying to make an ubuntu-based docker image that does a bunch of stuff and also creates files and directories on the host from time to time (in a bind-mounted folder). I'd like to set the umask so that permissions end up as desired, specifically to 0007 rather than the default 0022. I'm okay with changing the umask either at image build time or at container run time, though run time is preferred. But I don't want to mess with the entrypoint or the command since those are subject to change and compound commands can get complicated. My test is docker run --rm ubuntu bash -c umask and it always returns 0022. I've tried replacing 0022 with another value in /etc/login.defs, I've tried adding session optional pam_umask.so umask=007 to /etc/pam.d/common-session, /etc/pam.d/common-session-noninteractive, and /etc/pam.d/login, but those don't seem to have any effect. The only thing that works is create a file /etc/profile.d/umask.sh with the one-liner umask ${UMASK:-0022} and that works as long as I run commands with bash --login -c, but it would be great to not have to run a login shell but rather just to pass arbitrary commands to the docker. Ideally it should also be user-agnostic since I am changing the uid to match the host system. What is the right way to change the default umask for a debian image?

Why does setting umask to 0077 makes a gpg public key unavailable for apt when installing a package, e.g .

umask 0077
curl -fsSLo /usr/share/keyrings/brave-browser-beta-archive-keyring.gpg https://brave-browser-apt-beta.s3.brave.com/brave-browser-beta-archive-keyring.gpg 
  echo "deb [signed-by=/usr/share/keyrings/brave-browser-beta-archive-keyring.gpg] https://brave-browser-apt-beta.s3.brave.com/  stable main">/etc/apt/sources.list.d/brave-browser-beta.list
apt update
apt install brave-browser-beta

The above does not work, I get this output:

Err:4 https://brave-browser-apt-beta.s3.brave.com  stable InRelease    
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0B31DBA06A8A26F9
Reading package lists... Done
W: GPG error: https://brave-browser-apt-beta.s3.brave.com  stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0B31DBA06A8A26F9
E: The repository 'https://brave-browser-apt-beta.s3.brave.com  stable InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

This does work:

umask 0022
curl -fsSLo /usr/share/keyrings/brave-browser-beta-archive-keyring.gpg https://brave-browser-apt-beta.s3.brave.com/brave-browser-beta-archive-keyring.gpg 
  echo "deb [signed-by=/usr/share/keyrings/brave-browser-beta-archive-keyring.gpg] https://brave-browser-apt-beta.s3.brave.com/  stable main">/etc/apt/sources.list.d/brave-browser-beta.list
apt update
apt install brave-browser-beta

Why does setting umask to 0077 (and then downloading public key) makes a gpg public key unavailable for apt? The key was downloaded as root, and so was executed apt update, why then this issue?

About Samba I am reading the following valuable tutorial: * [How to Set Up a Network Shared Folder on Ubuntu With Samba](https://www.makeuseof.com/set-up-network-shared-folder-ubuntu-with-samba/) At the Step 2: Configuring Samba section appears the following configuration

[sambashare]
comment= Network Shared Folder by Samba Server on Ubuntu
path = /home/your_username/sambashare
force user = smbuser
force group = smbgroup
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
public = yes
read only = no

Observe that four parameters work with octal values. Just to avoid to do a disaster about configuration, about those octal values shown: With what command's logical approach are they based?: chmod or umask? **Observation** I am doing this question because for these parameters appear the mask and mode terms within their own names.

When using umask, I know that to get the resulting permission, the mask is first NOTed and then it is ANDed with the default permission (777 or 666). Now my question is, how was this formula derived? I mean, if **U** is the mask, **D** is the default permission, and **R** is the resulting permission, then where did R = D AND NOT(U) come from? It's not like someone has just thought of it out of nowhere.

I have a question regarding 'umask.' I have an extra disk on my Linux system, and I want it to mount during startup with the same permissions as '/home.' For example, my '/home' has these permissions:

d rwx r-x r-x  < Directories
- rw- rw- r--  < Files

I want any directories or files created on this extra disk to maintain these permissions. My '/etc/fstab' looks like this:

=BABABABABABA   /path/to/mount   ntfs   umask=0022,uid=1000,gid=1000   0   2

And my permissions for both directories and files are currently:

r-x r-x

Any suggestions or corrections are appreciated!

I have a vendor application installed in an Ubuntu Jammy server that relies on SSSD v2.6.3 configured for LDAP integration for the authentication and creation of the home directory of the user in the server. In the sssd.conf configuration it is present:

[sssd]
config_file_version=2
reconnection_retries=3
services=nss,pam
domains=mydomain.com

[nss]
...

[pam]
...

[domain/mydomain.com]
... ldap configuration ...
override_homedir=/sfs/home/%u

When user is authenticated the home directory created has the following set of permissions:

$ ls -lhtar /sfs/home
drwxr-xr-x 3 myuser mygroup 4.0K Jan  3 19:23 myuser

Unfortunately the permissions drwxr-xr-x give also access to others to navigate in their home directory. At the beginning I thought this was controlled by the PAM modules, in particular, the common-session executing the pam_mkhomedir.so module, **however this is not the case!!!**, since commenting this module does not have any effect, and also the home directory is always completely empty, not following the home "skeleton" usually provided in the mkhomedir e.g. session required pam_mkhomedir.so skel=/etc/skel/. I also noticed that the permissions drwxr-xr-x correspond to a umask 022 which is usually the default in the linux distributions, so I have modify to a 006 in /etc/login.defs and also add the umask 006 in /etc/profile to avoid the use of the 022 umask, however this attempt has been also in vain. is there anyone out there that has had this issue? How can you force the right umask when home directory creation is being triggered by the SSSD service? Thank you so much in advance!

let's say i have set the umask system-wide to 027 via a one-liner at /etc/profile.d/ on a multiuser-system. after some time resp. reboots i want to hide an existing desktop-file system-wide from the menu with the following commands:

# just in case the folder doesn't exist, create it:
sudo install -o root -g root -m 755 -p -d '/usr/local/share/applications/'

# copy the existing desktop file and preserve all attributes (which are permissions 644 for the old & new file):
sudo cp -vi --preserve=all '/usr/share/applications/application.desktop' '/usr/local/share/applications/'

# add or change the existing key to true:
sudo desktop-file-edit --set-key=NoDisplay --set-value=true '/usr/local/share/applications/application.desktop'

it kind of works, **but** not as intended: if you open alacarte this desktop-file is still activated but not shown in the menu! with a closer look at /usr/local/share/applications/ the reason can be found... the permissions of application.desktop are 640 instead of 644, so the file would still be shown but it can't be read by the normal user and hence it doesn't show up in the menu *(and therefore the correctly set NoDisplay=true does not really mater in this case)*. i even tried to the add the option -m 644 mentioned at the man page, but it seems to be exclusively for desktop-file-install. 1. is this behavior intended? and if so, why? 2. is there an easy workaround instead of using an appended chmod? 3. why does editing a file, change the permissions of it at all?!?

I'm using PHP script to connect to ssh server. It executes one command and exit. Connection is made to non interactive and non login shell. Because of that it does not load .bashrc or .bash_profile files so I can't set proper umask there. I googled some information on ssh inner workings and it seems that I can use ~/.ssh/rc file to execute some commands after ssh connection. My ~/.ssh/rc **on server** I am connecting: #!/bin/bash echo "Setting umask to 002" umask 002 echo "Umask set" The problem is that my umask is not set properly. When I run my script and it run umask command on server, I get 0022 umask : Run: cd /local/web/ && umask > Setting umask to 002 > Umask set > 0022 Why isn't it working?

I see numerous how-to examples for mounting an ntfs partition with either a mount command or an entry in fstab. In all cases, specifying ntfs as the filesystem is associated with also specifying umask=0222, and specifying ntsf-3g never has a umask parameter. Trying to research umask, I came across numerous explanations like this one . I can't get from those explanations to understanding "0222", which among other things, has one more digit than the specification seems to describe. I understand that it supposedly reduces permissions from the default definition. That's not much help, either. I'm guessing that it relates to writing, since in Linux, ntfs-3g supports it and at least as of a few years ago, ntfs did not. What are the default permissions (I assume they relate to the directories and files and are independent of the filesystem), and what does "0222" do to that? Why is it needed? Is it just to avoid an error message trying to write to a partition when Linux doesn't support it?

I have been using Linux & Unix for a long time. The first time I learned Unix is in a computer classroom with many students, where the instructor told us that you can use ssh to log in to remote workstations provided by the university I was studying in. In that context, I immediately know that Unix is a multi-user operating system because there were more students than workstations. (Pigeonhole principle.) Somehow after many years of use, I know basically what the umask (default to 022 for write permission to the user, 002 for write permission to groups of users such as teams) is and that the default permission of a user (and a new user) is 755 for folders, 644 for files. But after thinking a little deeper about it, it seems that the default permission setting is insecure in such a multi-user operating system. Although it makes sharing data easier, I still feel strange when you can easily list & copy other users' files within their home directory. So is why the default umask 002 or 022 in many Unix systems? Is there any historical reason that *traditional* Unix chose this design? (One possible reason I can think of is that, during 1970 ~ 1980 computers are used mostly in scientific research and the computing power is very limited. So when the early version of Unix comes out, they decided that the default permission should be for easy sharing instead of privacy protection.)

Have a wierd issue with permissions on files uploaded to a remote system. Locally, the file index2.html is chmod 664: acoder@acoder-local ~ $ ll index2.html -rw-rw-r-- 1 acoder acoder 29 May 17 14:46 index2.html After uploading this same file to the remote system, the permissions on the remote directory show: -rw-r--r--. 1 acoder acoder 3657 May 17 14:43 index2.html I first thought I had incorrect umask setting on the remote system, but... [acoder@remote public_html]$ umask 0002 For comparison, if I touch a file on the remote system, the correct permissions (for the given umask) show: -rw-rw-r--. 1 acoder acoder 0 May 17 14:44 index3.html So, how are permissions set on files uploaded via sftp? Why is umask ignored when placing files over sftp?

I am trying to set default group permission for the folder on FreeBSD 13.0

$mkdir test
$setfacl -d -m u::rwx,g::rwx,o::rx,mask::rwx test
$getfacl -d test
# file: test
# owner: john
# group: wheel
user::rwx
group::rwx
mask::rwx
other::r-x
$cd test
$touch file

$ls -l file
-rw-r--r--+ 1 john  wheel     0B Jul  9 19:32 file

$getfacl file
# file: file
# owner: john
# group: wheel
user::rw-
group::rwx              # effective: r--
mask::r--
other::r--

As you can see, the group permissions are not inherited properly. I do not care about the x flag for the user and group, that's a security mechanism. However, the group should have the write permission, which is not the case. The same behavior can be observed for folders created by the 'mkdir' command. On ArchLinux the same set of commands works just fine. On FreeBSD somehow umask takes over, which should be normally overridden by acls. If I change umask to 002, I get the desired result. On FreeBSD I am using UFS2 filesystem, on ArchLinux - ext4. Any thoughts about this?

A PL/SQL job **foobar622** writes files to UNIX/LINUX server using the following Oracle file I/O commands: UTL_FILE.FILE_OPEN UTL_FILE.PUT_LINE UTL_FILE.FILE_CLOSE In the past the files had these permissions: -rw-r--r-- 1 User_foobar_101 UnixGroup_101 563343 Apr 25 00:22 foobar622_fz.sql -rw-r--r-- 1 User_foobar_101 UnixGroup_101 563343 Apr 25 00:22 foobar622_fa.sql -rw-r--r-- 1 User_foobar_101 UnixGroup_101 563343 Apr 25 00:22 foobar622_fb.sql -rw-r--r-- 1 User_foobar_101 UnixGroup_101 563343 Apr 25 00:22 foobar622_fc.sql -rw-r--r-- 1 User_foobar_101 UnixGroup_101 563343 Apr 25 00:22 foobar622_fd.sql Now **foobar622** writes with these permissions: And I get a permission denied error when I try to open file in my editor. -rw-r----- 1 Unknown+User Unknown+Group 563343 May 22 00:22 foobar622_fa.sql -rw-r----- 1 Unknown+User Unknown+Group 563347 May 25 00:22 foobar622_fb.sql -rw-r----- 1 Unknown+User Unknown+Group 563333 May 25 00:22 foobar622_fc.sql -rw-r----- 1 Unknown+User Unknown+Group 563923 May 25 00:22 foobar622_fd.sql How do I go about restoring first default permissions? Is this an Oracle setting or a UMASK setting, or what?

Suppose I have two users Alice and Bob and a group GROUPNAME and a folder foo, both users are members of GROUPNAME (using Linux and ext3). If I save as user Alice a file under foo, the permissions are: -rw-r--r-- Alice Alice. However, is it possible to achieve that every file saved under some subdirectory of foo has permissions -rwxrwx--- Alice GROUPNAME (i.e. owner Alice, group GROUPNAME)?

I've been at this all day and think I finally figured it out, but want to make sure before I put it into production. I'm changing my server to allow the apache:apache user write permission on a few directories. I'm the only user jeff:jeff on the server. My directory structure looks something like this:

/home/jeff/www/                       0755 jeff:jeff
/home/jeff/www/example1.com/          0755 jeff:jeff
/home/jeff/www/example2.com/          0755 jeff:jeff
/home/jeff/www/example2.com/uploads/  0755 apache:apache

**The problem is:** I run chmod apache:apache uploads/ to allow apache write access. Whenever I want to edit a file in uploads/ via sftp, I have to chown it back to jeff:jeff, then reverse when I'm done. **My preliminary solution is:** - Add apache user to jeff group - Give jeff group write permission on uploads/ dir via manual chmod 775 - Force apache user to create any new files + folders + subfolders as apache:jeff. Requires setgid 2775 on uploads/ dir - Force apache user to create any new files + folders + subfolders with umask 002 = 775 via [systemd](https://stackoverflow.com/a/31154944/142233) I'm only about 50% sure I've got all this right. Does it sound okay? Is there a better way? Did I miss anything? **With Jim's help, here is the final solution I used:** For my reference.

# usermod --append --groups apache jeff

> Relogin all sessions

# chown -R apache:apache www/example.com/uploads/
# find www/example.com/uploads/ -type d -exec chmod 775 {} \;
# find www/example.com/uploads/ -type f -exec chmod 664 {} \;

# systemctl edit --full php.service

-----------
[Service]
UMask=0002
-----------

# systemctl daemon-reload
# systemctl restart php

WordPress users will want to add this to their wp-config.php:

define('FS_CHMOD_DIR', 0775);
define('FS_CHMOD_FILE', 0664);