AWS Lightsail Django Error: PermissionError at / [Errno 13] Permission denied:

Keywords: Django - Linux - Technical issue - Permissions
bnsupport ID: b89617f8-d307-f876-8995-6db8bdaf0298
Description:
My Python script is unable to write to a directory which is set as follows: bitnami:bitnami, 777. I have also attempted mixed ownership for the directory (bitnami:daemon). However, that did not resolve my issue. I am able to execute scripts in the same directory which only require Read permissions. Thank you in advance for any help!

Sorry for the correction to my post: I meant to state “…able to execute scripts in the same directory which only require XR permissions.”

Sorry again for replying to my own post, but yes, I know that 777 is a bad idea. I’m simply trying it as a way of testing/troubleshooting. :slightly_smiling_face:

Hello @TrailGuy,

It is indeed strange, did you execute your chown/chmod permission recursively? Please try the following:

sudo chown bitnami:daemon -R yourfolderpath
sudo chmod 777 -R yourfolderpath

As you said, once you are able to solve the issue, you should adjust the permissions to avoid potential securities vulnerabilities.

Regards,
Francisco de Paz

1 Like

Hi Francisco!

Thanks so much for the response. Yes, I executed chown/chmod recursively early on in my troubleshooting. I greatly appreciated your code; unfortunately, it did not work.

Perhaps a little more context may help. My Python script accesses a remote dataset through an API and returns records that are written to an HTML file, which constructs a graphically-intensive dashboard. It runs fine on my local machine and another VPS. However, on Amazon Lightsail’s Bitnami stack, I get the aforementioned errors. I tried looking at the /etc/passwd and passwd- files, but everything seems OK, i.e, passwd contains the following entry:
bitnami:x:1000:1000:Debian:/home/bitnami:/bin/bash
I also added the user bitnami to the daemon group per the following post:
https://community.bitnami.com/t/permission-issues-recommend-solution-dont-work/53235/8
sudo adduser bitnami daemon

2 questions:

  1. Is a particular deployment of the Bitnami stack ever modified by a 3rd party like Amazon, e.g., use of a daemon that kills processes like creation of an HTML file and writing to it? (perhaps through detection of request/response objects, which are instantiated by my script)
  2. What other configuration files could I try to modify? (I’ve tried different things in the httpd.conf and related Apache config. files, as well as the above-mentioned passwd files)

Thanks in advance; any help is greatly appreciated!

Hi @TrailGuy,

As far as I know, AWS shouldn’t be overriding any service nor process in your instance, but I couldn’t say 100% sure. Could you share the exact permission error you are getting when you execute your script?

I would also suggest you to debug the issue starting by using a sample script to create a file in your selected path, checking whether changes to the file’s permissions or running it as sudo makes any difference.

Regards,
Francisco de Paz

1 Like

Hi Francisco,

Thank you for your continued patience and help. Your tip to run the code as sudo was especially helpful and caused me to understand an error in my coding that was contributory - I had a relative path to the file that my Python script was writing to the directory. This caused the written file to have root:root assignment instead of bitnami:daemon. I changed the path to the file being written to absolute and I noticed that permissions were assigned according to those I specified for the directory, which is what I wanted. This caused the script to “somewhat work.” Since I’m still investigating other peripherally-related issues, is it OK if I wait to close the post (I know about the 14-day thing)?

Possible Explanation? Am I correct to assume that the following explains the above behavior? When I used a relative path, the process was not “aware of” how to assign ownership to the file my script was creating and writing to, so it chose the most secure setting - root:root. When I changed the path for the file being written to an absolute path, the process was being “guided” from root. When it reached my directory, directory-level permissions were exposed, so the process was able to assign these per what I intended (directory-level permissions of 777). As a result, my script ran.

It actually assigned default permissions of 775, but the script ran, which was good.

Hi Francisco,

Yes, the cause of the issue was the use of a relative path instead of an absolute path for the location that my script was writing to. When I switched it to an absolute path, the permission issue was resolved. Again, thank you so much for your help. Also, big thanks to you and your engineer colleagues at Bitnami for a great stack. Keep up the great work!

1 Like

Hi @TrailGuy,

I’m glad you could solve the issue! Thanks for your words and for sharing the issue’s explanation with the community! Do not doubt to reach to us again if you encounter any other issues.

Regards,
Francisco de Paz

1 Like