Member Avatar for NardCake

Hello! So I've always had trouble with permissions/directory ownership and I can't figure this out...
I have my apache directory in my home directory (/home/apott/www). I can edit files over FTP and such which is fantastic but I apache doesn't have permission to access the files... I can give it permission but it seems to only work for what's in the directory at that time, and once I add something new, it doesn't have permission.

So I need the ultimate solution... (I didn't mean to make that sound uhh... just nvm xD)

  1. I need to be able to edit files in this directory.
  2. Apache needs to be able to access all the files.
  3. My CGI applications need to be able to access some files. (this isn't VERY important as I can place files elsewhere I suppose...)

I apologize for my lack of knowlege in this department but any help is very much appreciated!
Thanks!

  • 3 Contributors
  • 7 Replies
  • 231 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by NardCake

Dani AI

Generated

Short diagnosis and a practical fix summary based on the thread: Apache gets a 403 because it can’t read or “search” the path to the files. New files you upload are coming in with permissions or group ownership that don’t allow the Apache process to read them, so you have to reset permissions after each upload. As recommended, fixing ownership helps; as pointed out, group-based access is the right model for a production site — but you also need mechanisms that make new files inherit the site group and suitable permissions automatically.

Immediate checklist (apply in order):

  • Confirm Apache can traverse the path. Parent directories must have the execute (x) bit for Apache to enter them (not just read on the files). (unix.stackexchange.com)

  • Make the web directory grant group read/execute and ensure new files inherit the group. Two useful, non-destructive steps are:

    # make existing tree group-readable and directories executable
chmod -R g+rwX /home/apott/www

# make the directory inherit its group for new files
chmod g+s /home/apott/www

    The setgid bit on a directory causes files created inside to inherit the directory’s group. (man7.org)

  • Stop having to chmod each upload: set a default ACL that gives the site group the rights you want for any new files and subdirs:

    setfacl -R -m d:g:apott-site:rwX /home/apott/www
setfacl -R -m g:apott-site:rwX /home/apott/www

    Default ACLs make newly created files follow the ACL rules instead of depending solely on umask. (baeldung.com)

  • If uploads still get restrictive perms, check your FTP server’s umask (vsftpd/ProFTPD have settings that determine the mode of created files). Adjust it so uploaded files are group-readable (for example a umask that yields 664/775 as needed). (docs.redhat.com)

Extra troubleshooting / production notes:

  • Check Apache error logs for “search permissions are missing on a component of the path” — that pinpoints missing execute bits.
  • On SELinux-enabled systems, files under a user home are often labeled to block httpd; you may need to set the correct httpd file context or enable home-dir access booleans (use ls -Z, semanage fcontext + restorecon). (docs.redhat.com)

For production, keep the per-site user/group separation suggested, run CGI/PHP in per-site sandboxes (suEXEC or per-site PHP-FPM pools), and let group+SGID+ACL handle file permissions so uploads don’t break the site.

Recommended Answers

All 7 Replies

Member Avatar for onsponge

heyhey not too sure about this, but have you tried changing the ownership of the directory recursively?

chown -R apott:www-data

perhaps?
sorry not much of a help =x

Edited by onsponge
Member Avatar for cereal

If this is not a production server, but only for testing, you can add your user to www-data group:

usermod -a -G www-data apott

If in this server there's another user added to the same www-data group he would have the ability to read or rewrite your code. The same happens with onsponge suggestion. I tend to use this approach when testing, but only because I'm using my box. So be careful with this solution.

In production context you should create a user and a group for each website, for example website123, or in your case apott, and then add the www-data user to the website group. That way the website user cannot access to the other websites scripts, but Apache can because is member of each group:

usermod -a -G website123 www-data

Regarding your CGI scripts you could use SuexecUserGroup:

or just follow the previous suggestions. Please, correct me if I'm wrong.

Member Avatar for NardCake

Okay guys, thanks for the help but I'm still having issues...
Okay cereal, this is what I have done: (This is production)
groupadd apott-site
usermod -a -G apott-site www-data
usermod -a -G apott-site apott

mkdir www
chgrp apott-site www

Apache still can't access files -.-
Thanks for any help though!

Edited by NardCake
Member Avatar for cereal

If the ftp user is not apott then add it to the apott-site group. That should fix the problem.

Edited by cereal
Member Avatar for NardCake

Maybe this isn't even the best setup for production?
I just want a good way to setup apache for production.

Member Avatar for NardCake

The ftp is working fine, I'm saying Apache is getting a 403 error cause it can't access the files.

Member Avatar for NardCake

I have to change the permissions everytime I add a file, is this really necessary?
Oops, sorry for triple post.
Thanks!

Edited by NardCake
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.