Scenario: A file created under computer A (userA), which takes file ownership as userA in file permissions, is then transferred to computer B with a different user (userB)....

Does the ownership of the original file change from the original user (userA) in computer A to the user (userB) of computer B?

How can I create a file that is only writable by me, the creator and owner, and only readable to anyone who might receive that file on other computers?

I created a testfile.txt with file permissions 755 on computer A (userA) to compare the permissions and ownerships of this file before and after I transferred it using scp from computer A to B. I noticed how my original file, now on computer B, has the user id as userB instead of userA [where the file was created].

Computer A, having 'userA'

rwx-r-x-r-- userA testfile.txt

Computer B, having 'userB'

rwx-r-x-r-- userB testfile.txt

I thought, and wanted, to make the file only readable, writeable, and executable by the owner (which I thought would be the user from the computer I created the file in).

Thanks! I am new at this!

3 Answers 3



This all depends on who creates the file on the destination. Try this:

$ touch some_file
$ ls -l some_file
-rw-r--r-- 1 userA userA 0 Apr 9 17:44 some_file
$ ls -ln some_file
-rw-r--r-- 1 501 501 0 Apr 9 17:44 some_file

So in my example, userA's numeric uid is 501.

Now transfer it, logging into the remote system as userB:

$ scp some_file userB@computerB:
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 userB users 0 Apr 9 17:50 some_file
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 1743 20 0 Apr 9 17:50 some_file

As you see here, userB created the file, and userB has numeric uid 1743. See also how the timestamp changed?

This is the default behavior of scp. You can preserve attributes though by using scp's "-p" option. This only preserves timestamp and permissions -- and importantly, not ownership. This might be exactly what you're looking for:

$ scp -p some_file userB@computerB:
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 userB users 0 Apr 9 17:44 some_file
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 1743 20 0 Apr 9 17:44 some_file

Note that besides scp, there are many different ways of creating files on remote machines -- NFS, FTP, WebDAV... these will behave in different, but similarly predictable ways. Let's not get carried away though -- you asked about scp.

(OT note, you actually created the file with 754 permissions! rwx=111=7, r-x=101=5, r--=100=4 – you see, r, w and x are bits in an octal word where r=4, w=2, x=1. That's why you'll see references to octal in relation to permissions. Thanks ernie for the correction!)

  • Great! So permissions on files, specifically permissions of 'owner', are basically more for the management of files under the same system (with different user accounts presumably)? Since any filed transferred to another computer system will override that file's ownership with that of the new system....correct? If so, is there a way to maintain ownership of a file that you can transfer around systems that can not gain owner access? -Thanks!
    – bretonics
    Apr 10, 2013 at 14:02
  • 1
    Those permissions at the end (e.g. 111) aren't octal, they're binary. The 7, 5, and 4 could be considered octal (or any number system with a greater base), though I assume you were trying to convey the decimal equivalents.
    – ernie
    Apr 10, 2013 at 18:29
  • 1
    @macam it sounds as if you're asking to create a file that's read-only everywhere. This isn't really possible, unless you write the file, then change the permissions. If a user was able to write the file to disk, then they're going to be able to edit it. Note that some file formats allow you to create read-only versions of files, but that only means read-only within their tools (PDF is a good example of this). You could still modify the underlying 0s and 1s directly.
    – ernie
    Apr 10, 2013 at 18:31
  • Correct ernie, I was thinking octal, writing binary... what a silly mistake! I'll update it so it's not factually incorrect.
    – Rich
    May 17, 2013 at 0:10

The general form for scp when you're copying locally to remote is:

scp localfile username@remotehost:/some/remote/directory

In this case, you're telling scp you want to login as username on the remote system, and that's the username the write will ocurr with. Most likely in your example, you used userB when you were scp'ing the file to computer B.

If you were copying a remote file to a localhost, e.g.:

scp username@remotehost:/some/remote/file /some/local/directory

In this case, you login as username to the remote system, and then write it locally as the user you're running the scp command as. This example will copy the file from the remotehost to the system you're running on, as the user you're currently logged in as (since the write will be performed by the currently logged in user). This will not affect anything on the remotehost, as you're only reading the file from there, and copying it to the localhost. Since you're able to read the remote file, the local file has to have write permissions for you, as you're writing the file locally.

Put another way - the owner of the file will generally match the writer of the file. So, if you're logged in as userA, and write a file, the owner will be userA. A simpler example might be something like this:

user@server:~$ ls -l /var/log/syslog
-rw-r----- 1 syslog adm 6615 Apr  9 17:09 /var/log/syslog  

Note that this file is owned by syslog but that it's readable by anyone in the adm group, which user happens to belong to. Then if we copy the file to user's home directory (~/):

user@server:~$ cp /var/log/syslog ~/
user@server:~$ ls -l ./syslog
-rw-r----- 1 user user 6615 Apr  9 17:10 ./syslog

Note that the copied version of the file is now owned by user. scp is doing the same thing, except the source or destination may involve logging in as a different user to a different system.

Note that permissions are tracked with the user id, a numeric represenation of the user. You can see your current UID with the id command. In general, for individual systems, UIDs will not be the same system to system as the accounts are not shared (unless you're using LDAP or similar). I believe that traditionally, 0 is root, UIDs less than 1000 are reserved for system accounts (e.g. mail, news, bin, daemon, etc), and that regular users start at 1000. As far as I know, regular user UIDs are assigned sequentially, so if you created three accounts, they would likely be 1000, 1001, and 1002.

Back to your original question of how to send a read-only file, you have to ensure that the reader on the remote system does not have the same UID as the owner of the file. i.e. if you (userA) were preparing a file for userB, you could do something like:

scp localfile userA@remotehost:/some/remote/directory

In this case, the owner of the file will end up being userA, (and we know userA exists on the remote system as that's who we're logged in as), and userB would not have write permissions (assuming the file was originally 755). Edit: you may need a -p to preserve the permissions?

Of course, if userB has root or sudo permissions, they'll be able to make the file writeable no matter what you do.

  • So I tried the second code "scp username@remotehost:/some/remote/file /some/local/directory" login as the username of the remote system (userB) and writing the file locally as the userA from the local system. However, checking the owner of the file on computerB, the file again had the 'userB' owner. You did mention ids are tracked with a numeric representation and that UIDS will not be the same system to system as the accounts are not shared, but how come both my UIDS for both systems have the same UID #, thought userA does NOT exist on computerB? Is that why the file ownership is transferred?
    – bretonics
    Apr 9, 2013 at 23:51
  • Also, do all usernames from different computers have the same UID#? I tested 3 Macs, all having the same UID#, even one that was not mine.
    – bretonics
    Apr 9, 2013 at 23:55
  • I edited the answer - short version is that the second version of SCP will not affect the remote version of the file - it only reads it, and then writes the file locally, as the user running the scp command. UIDs are generally assigned sequentially, starting at user 1000.
    – ernie
    Apr 10, 2013 at 0:04

When you transfer a file from the source to the destination, the permissions and indeed the ownership are subject to the parameters of the transfer. As @ernie said, ownership depends on how you transfer the file.

Permissions depend on the umask of the file.

For old-school FTP servers, umask is usually set in the FTP server configuration. For SFTP servers (cp over SSH, or scp), you have to set up PAM plugins for ssh according to this answer over on server fault.

  • So transferring via scp transfers ownership? How do you send a file to someone without changing the ownership of the file to their UID?
    – bretonics
    Apr 9, 2013 at 23:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .