I have a Django app which is configured to write db queries into a /tmp/db.log file.

        "debug_console_to_file": {
            "level": "DEBUG",
            "filters": ["require_debug_true"],
            "class": "logging.FileHandler",
            "filename": "/tmp/db.log",

The application usually starts from a uwsgi server using www-data as a user. However, sometimes I manually run it (with python manage.py) via my user - tvelichkov.

The problem is that when I try to start it from my user, I got a Permission denied error to /tmp/db.log file since www-data has already created it (removing the file can temporary fix the issue, but then the server will receive the same error, since now my user owns the file).

    PermissionError: [Errno 13] Permission denied: '/tmp/db.log'

I've tried to add my user to www-data group

    $ members www-data
    www-data tvelichkov

I've also tried to give 777 file permissions to the file.

    $ ls -l /tmp/db.log 
    -rwxrwsrwx 1 www-data www-data 22102 юли 30 15:25 /tmp/db.log

But I still keep getting this Permission denied error. Any help would be appreciated.

Note: I used to have no issues with this setup in Ubuntu 18.04, but now I have it in Ubuntu 20.04.

UPDATE: Here are the permissions of the /tmp/ folder, but note that this is after I ran chown root:root /tmp and chmod 777 /tmp as suggested by @adrian vera, BTW after this change seems like chmod 777 /tmp/db.log is working, because I no more get the Permission denied error. Is it possible that Ubuntu changed something for the /tmp/ folder between versions 18.04 and 20.04 ? Because I'm pretty sure I didn't change anything to this folder before running into this issue?

    $ ls -l / | grep tmp
    drwxrwxrwx  24 root root       4096 авг  3 10:19 tmp

Note2: I have one more machine with clean Ubuntu 20.04 install where I have this issue too, I will double check the permissions there too once I got home.

UPDATE2: So on a clean Ubuntu 20.04 install the permissions of the /tmp/ folder are:

    $ ls -l / | grep tmp
    drwxrwxrwt  23 root root      12288 авг  3 16:41 tmp

And this is how the /tmp/db.log look like:

    $ ls -l /tmp/db.log 
    -rw-r--r-- 1 www-data www-data 0 авг  3 16:54 /tmp/db.log

    $ sudo chmod 777 /tmp/db.log 
    $ ls -l /tmp/db.log 
    -rwxrwxrwx 1 www-data www-data 0 авг  3 16:54 /tmp/db.log

    $ lsattr /tmp/db.log 
    --------------e----- /tmp/db.log

    $ whoami

    $ getent group www-data

    $ python manage.py test --settings=cs.settings.test
    Traceback (most recent call last):
      File "/home/tvelichkov/.pyenv/versions/3.6.10/lib/python3.6/logging/config.py", line 565, in configure
        handler = self.configure_handler(handlers[name])
      File "/home/tvelichkov/.pyenv/versions/3.6.10/lib/python3.6/logging/config.py", line 738, in configure_handler
        result = factory(**kwargs)
      File "/home/tvelichkov/.pyenv/versions/3.6.10/lib/python3.6/logging/__init__.py", line 1032, in __init__
        StreamHandler.__init__(self, self._open())
      File "/home/tvelichkov/.pyenv/versions/3.6.10/lib/python3.6/logging/__init__.py", line 1061, in _open
        return open(self.baseFilename, self.mode, encoding=self.encoding)
    PermissionError: [Errno 13] Permission denied: '/tmp/db.log'
  • Do not set /tmp to 777. It should be left at 4777. Otherwise you have created a huge security hole. See this for details.
    – vidarlo
    Commented Aug 3, 2020 at 8:26
  • Can you please add output of lsattr /tmp/db.log
    – Digvijay S
    Commented Aug 3, 2020 at 12:17
  • @DigvijayS yes, its: --------------e-----, I've also updated it in the question.
    – Todor
    Commented Aug 3, 2020 at 14:15
  • 1
    See askubuntu.com/questions/1250974/… To restore the 18.04 behavior, run sudo sysctl fs.protected_regular=0
    – ubfan1
    Commented Aug 3, 2020 at 16:16
  • Holy sh**, @ubfan1 yep I can confirm this setting is causing the issue, no more errors with fs.protected_regular=0. However, reading about this settings, I feel like its more appropriate to go with @pa4080 approach, it looks like a more general fix, which better fits to the bounty description (Otherwise I would have asked you to post this comment as an answer so I can give you the bounty). Anyway I just wonna finish this with a BIG THANK YOU.
    – Todor
    Commented Aug 4, 2020 at 7:02

2 Answers 2


Probably, instead of deal with the permissions, in this case, it is a better idea to execute the script as the www-data user. This is standard approach which we use to run the maintenance scripts of some web apps like NextClud, MediaWiki, etc. You can do that by the help of the sudo command:

sudo -u www-data python manage.py
  • I agree that this is probably the best approach not dealing with permissions. I just wonna give some more fight to the permission issue, since its something that used to work, and I wonna learn why it stopped. BTW, using your code as-is throws sudo: python: command not found, I guess full path to python is required and since we use virtual envs: sudo -u www-data /home/tvelichkov/.pyenv/shims/python manage.py works OK.
    – Todor
    Commented Aug 3, 2020 at 8:22
  • 1
    @Todor, yes your python apparently doesn't belong to the default $PATH and you need to use the full path to the executable. I appreciate your curios to look deep as possible into the problem. Just keep in mind if you deal with the permissions of directories like /tmp they will fall back to the defaults after each reboot, so you will need to execute additional script...
    – pa4080
    Commented Aug 3, 2020 at 8:31

It looks like you have set particular user id as group ownership of file. (See s in rwxrwsrwx file permissions details.) That's why you are getting permission denied with tvelichkov username. You need to turn off user id and set group id in file ownership.

sudo chown g-s www-data: /tmp/db.log

I would suggest that you should use same user to run and test application. That would avoid these kind of issues.

  • Are you sure this is exactly the command, because it throws chmod: cannot access 'www-data': No such file or directory. Btw after restart the default file permissions are: -rw-r--r--. And seems like I may have changed something to the /tmp/ folder, because following @adrian vera answer, after running chown root:root /tmp and chmod 777 /tmp, only now running chmod 777 /tmp/db.log generates -rwxrwxrwx (i.e. no s) and indeed there is no error anymore! Did I correctly restored the /tmp/ folder and can i somehow change the default file permissions to be different than -rw-r--r--?
    – Todor
    Commented Aug 3, 2020 at 6:40
  • /tmp folder typically have the permission rwxrwxrwt. The last t is required so that a user can not delete files created by other users. To set this bit use sudo chmod o+t /tmp. Since you have added yourself to www-data group you can have permission 664 on the db.log file.
    – turbulence
    Commented Aug 3, 2020 at 7:24
  • @turbulence, now after I added t as you suggested the tmp forlder permissions are drwxrwxrwt, I've also changed the db.log perms to 777 and now they are: -rwxrwxrwx and started getting the error back. I'm not sure how exactly logging.FileHandler works internally, (if he tries to delete the file before using it, could this be reason for the error? But i've just tested the exactly same setup (permission wise) on one of my colleges machine with Ubuntu 18.04 and it WORKS. Everything is the same, except I'm running 20.04 and got the error.
    – Todor
    Commented Aug 3, 2020 at 7:57
  • Make sure that you have sudo access or you can switch to root to change ownership.
    – KK Patel
    Commented Aug 3, 2020 at 13:56
  • @todor Can you show what command exactly you tried ans throw error ?
    – KK Patel
    Commented Aug 3, 2020 at 14:39

You must log in to answer this question.

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