1

When I run my program and try to create a file, I am getting the following error:

IOError: [Errno 13] Permission denied: '/home/giri26/couponmonk_project/user_15_qr.png'

I run my program using supervisor and this is the config file:

[program:gunicorn-couponmonk]
directory = /home/giri26/couponmonk_project
command = /home/giri26/venv/py2.7/bin/python /home/giri26/venv/py2.7/bin/gunicorn --worker-class socketio.sgunicorn.GeventSocketIOWorker __init__:app 
stdout_logfile = /var/log/gunicorn/couponmonk-std.log
stderr_logfile = /var/log/gunicorn/couponmonk-err.log
user = newuser

I thought this error was referring to the permissions for newuser so I added newuser to the group giri26.

Running groups newuser results in:

newuser : giri26

The results of ls -ld couponmonk_project/ is:

drwxrwxr-x 3 giri26 giri26 4096 Jun 27 22:34 couponmonk_project/

I figured that as newuser is part of the group giri26 and the group has rwx permissions, then I would be able to write and create files in the couponmonk_project folder.

Am I looking at this correctly?

Thanks for your help.

NOTE

The folder above has the following permissions:

drwxr-xr-x 10 giri26 giri26 4096 Jun 27 22:52 ../

Does this need to change perhaps?

UPDATE

As suggested below, I ran strace with curl but the output did not contain any instances of EACESS. There are 400+ lines in the output file so can't really post it all here. Is there anything else that I might look out for? ATM, I can't really tell what is relevant.

These lines appears a lot:

762   access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
762   open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY) = 3
762   read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\r\0\0\0\0\0\0"..., 832) = 832
762   fstat(3, {st_mode=S_IFREG|0644, st_size=14768, ...}) = 0
762   mmap(NULL, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa0d731f000
762   mprotect(0x7fa0d7321000, 2097152, PROT_NONE) = 0
762   mmap(0x7fa0d7521000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fa0d7521000
762   close(3) 

Also this appears towards the end of the output:

recvfrom(3, "HTTP/1.1 500 INTERNAL SERVER ERR"..., 16384, 0, NULL, NULL) = 10510
Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
  • Did you restart supervisor after doing the group changes? They will not apply before. – Klaus D. Jul 06 '15 at 08:46
  • @KlausD. Yep, I've tried this but still having the same issue. –  Jul 06 '15 at 13:51
  • Does the file already exist? If so, what are its permissions? – Andrew Henle Jul 06 '15 at 13:53
  • @AndrewHenle The file doesn't exist. It is about to be created when the error occurs. –  Jul 06 '15 at 13:55
  • @Giri - What's your OS? If Linux, try running the process under `strace -f -o /your/output/file/name your command` and look for a the system call that returns `EACCESS`. That will tell you the exact system call that failed, which is more data than you have right now. – Andrew Henle Jul 06 '15 at 22:17
  • @AndrewHenle I am running `Debian 7`. I updated my question above. Unfortunately, I couldn't see an instance of EACCESS –  Jul 09 '15 at 11:50

2 Answers2

0

The line in your gunicorn configuration file

user = newuser

does appear to be the central problem. As is sorta shown by

$ id
uid=1001(msw) gid=1001(msw) groups=1001(msw),4(adm),8(mail) …

A user has one uid and one gid. All other groups listed are groups that you belong to but are not your gid. To change the gid you have to explicitly ask for it to be switched as in:

$ newgrp mail
$ id
uid=1001(msw) gid=8(mail) groups=1001(msw),4(adm),8(mail) …

does change my gid to one of my other groups. Unfortunately newuser probably now looks like:

 $ id
 uid=22(newuser) gid=22(newuser) groups=22(newuser), 455(giri26) …

and since newuser might never log in to a shell nor even have a password, there is no good place to run newgrp.

To fix it, you should make giri26 the gid of newuser by modifying /etc/passwd

newuser:x:22:22: …

becomes:

newuser:x:22:455: …

This could have effects on newuser's other files and directories, be wary.

msw
  • 42,753
  • 9
  • 87
  • 112
  • Thanks @msw. I ran the commands in your response and got the following for `newuser`: `uid=1001(newuser) gid=1000(giri26) groups=1000(giri26)`. –  Jul 07 '15 at 05:53
0

You should try and restart the actual machine after making the file permission changes.

If you are running this on a remote server, issue a command via the web host control panel to reboot the actual machine.

This should hopefully solve the issue.

Osborne Cox
  • 466
  • 2
  • 7
  • 19