Target situation:

  • data/file.txt owned by myUser:myUser and "-rw-rw-rw-" (chmod 666)
  • symbolic link /tmp/file.txt owned by postgres:postgres and "-rw-rw-rw-"

So, I can edit the file with my user, and the other user (postgres) can read and write it also, but the link and the file are owned by different users.

Real world situation: same step by step of this other question,

sudo rm /tmp/file.txt  # if exist, remove

cd ~
sudo chmod 666 data/file.txt
ls -l data/file.txt    # "-rw-rw-rw-" as expected
more data/file.txt     # working fine
sudo ln -sf $PWD/data/file.txt /tmp/file.txt  # fine
ls -l /tmp/file.txt    # "lrwxrwxrwx",  /tmp/file.txt -> /home/thisUser/file.txt
more /tmp/file.txt     # fine

sudo chown -h postgres:postgres /tmp/file.txt

sudo more /tmp/file.txt   #  NOT WORK! 

A workaround is sysctl -w fs.protected_symlinks=0 (then more /tmp/file.txt will work fine) but it is not secure; I need another solution.

See real-life problem here


The directories /home and /tmp aren't really appropriate for this, and neither is using a symbolic link. Make a directory to store the file and set up permissions for it using an ACL. Let's say that your username is peter. Some of the commands below might be superfluous, and these are given merely to be explicit.

# Make a new directory to store the `file.txt`.
sudo mkdir /var/my_dir

# Change ownership and group ownership to root.
sudo chown root:root /var/my_dir

# Only allow root and members of root to read the directory.
sudo chmod 0750 /var/my_dir

# Begin to augment standard permissions with ACLs.

# Below, allow peter rwx for all new file system objects in /var/my_dir.
# (-d means "default" and -m means "mask")
setfacl -d -m u:peter:rwx /var/my_dir

# Set the same mask for the directory itself.
setfacl -m u:peter:rwx /var/my_dir

# Below, allow postgres r-x for all new file system objects in /var/my_dir.
setfacl -d -m u:postgres:r-x /var/my_dir

# Set the same mask for the directory itself.
setfacl -m u:postgres:r-x /var/my_dir

Now, peter can create files in /var/my_dir, and postgres can read them.

It may also be convenient to link the directory in your home directory.

cd && ln -s /var/my_dir .

Files in /tmp should disappear on reboot. Generally speaking, or perhaps arguably, it would not be a good practice to link to files in your home directory. I could expound on that statement if you don't already understand. A better location for this purpose might be /usr/local/var/my_dir, but the main point is to try to get the permissions right instead of using /tmp and /home with symbolic links for this purpose.


This might also be done in a standard, simpler way that would be more compatible with other software like SFTP/SCP clients.

sudo mkdir /var/my_dir
sudo chown peter:postgres /var/my_dir
sudo chmod 0750 /var/my_dir

Now, whatever files exist in /var/my_dir can only be read by root, peter and postgres, while only peter and root can write.

Then just make sure your umask creates files that postgres can read.

touch test
ls -l test

If the result shows r for "others," then postgres will be able to read the file in /var/my_dir.

Yet another approach...

sudo touch /usr/local/var/file.txt
sudo chown peter:postgres /usr/local/var/file.txt
sudo chmod 0640 /usr/local/var/file.txt
ln -s /usr/local/var/file.txt .

Above, we work with a single file, no directories. Again, all of these are simply setting permissions. You merely have to decide how you want to approach the situation, having more knowledge about what you are doing than what we can read in the question.

  • Seems a solid solution... Make sense. But I never user ACL: what the difference using setfacl or usual chown/chmod commands? – Peter Krauss Jan 11 '17 at 20:50
  • Thanks! For readers that not known ACL, a good start point for UBUNTU: help.ubuntu.com/FilePermissionsACLs. It is a standard, "POSIX ACL", and is default (not need apt install) for UNUNTU 16 LTS. – Peter Krauss Jan 11 '17 at 22:27

There is a misconception here. There is no point in changing the rights of a symbolic link. Quoting the chmod manpage (bolding is mine):

chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used.

No need of symlinks. To share your file with PostgreSQL, you must change the group-owner of the file to the group of user postgres (that is postgres on Debian-like systems), then chmod g+rw your file.

  • Thanks! Yes, I only remove sudo chown -h postgres:postgres /tmp/file.txt and now work fine with psql ... But the problem exist (will back eg. after boot), as @Christopher explained, because I linking with /tmp... So both are correct. – Peter Krauss Jan 11 '17 at 20:48
  • 1
    Your information is out of date. Read about protected symbolic links, referenced in unix.stackexchange.com/a/336631/5132 and implemented in Linux four and a half years ago. The owner (note that it is chown not chmod) of a symbolic link nowadays is used. – JdeBP Jan 11 '17 at 20:51
  • I repeat: note that it is chown not chmod. – JdeBP Jan 11 '17 at 21:00
  • I've already pointed you to an answer where Christopher did exactly that. (-: – JdeBP Jan 11 '17 at 21:04
  • Sorry @JdeBP for my stubbornness, I have now taken the time to read the page linked to by Christopher in his answer and now I understand what you meant. I'll correct my answer. Thank you. – xhienne Jan 11 '17 at 22:34

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.