We have a new CentOS 8 server that we are running into issues with when trying to create files/directories over SSH. For example, while on the server as the user we are using to SSH I can create a directory and it defaults the permissions to 755. However, if I am on another server and use the following command it will create the directory with 700 permissions

ssh user@newserver mkdir /home/user/testdir1

The same goes for files, on the server as the user I create a file, it gets 644 permissions. Creating the file over SSH it gets 600 permissions.

ssh user@newserver touch /home/user/testfile1

What am I missing?

  • @l0b0 has added an answer below. However it is important to know that the problem has nothing to do with ssh. It is good to look at what is different, however sometimes it is not the most obvious difference. Oct 30 '20 at 21:18

The default permission when creating a new file is defined by the umask on the machine in question. The umask is an octal number which is subtracted from 0777 (binary 0b111111111) to determine the default permissions for the user (leftmost three bits), group (middle three bits) and other (last three bits). For example:

$ umask
$ touch first
$ mkdir first-dir
$ ls -l
total 4
-rw-rw-r-- 1 user group    0 Oct 31 09:55 first
drwxrwxr-x 2 user group 4096 Oct 31 09:55 first-dir

0002 is equal to 0b000000010, and as you can see the eighth bit (writable for other users) has been cleared on both the file and directory.

As you can also see, the file did not get executable bits and the directory did. This is for practical reasons: a directory needs to be executable to be able to list its contents, and most files shouldn't be executable.

See man umask for details, and the Bash startup files on the machine in question to see where umask is set.

  • What I think you're missing here is that the umask may be (and in this case probably is) set in the login session settings, and that these settings aren't activated for a non interactive session such as the ssh commands shown by the OP
    – roaima
    Oct 30 '20 at 21:23
  • Why not add another answer @roaima?
    – l0b0
    Oct 30 '20 at 21:56
  • Because yours is right - but it's missing the link from the OP's problem description to your explanation of the underlying reason.
    – roaima
    Oct 31 '20 at 8:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.