Member Avatar for dshiells

Hi,

When logged into my Amazon EC2 instances as user ec2-user, I cannot edit/delete files in my web root folder.

All files are owned by apache:apache, and I have added ec2-user to the apache group. What am I missing?

To sum up:

[ec2-user@xxx ~]$ groups ec2-user
ec2-user : ec2-user wheel apache


[ec2-user@xxx ~]$ id ec2-user
uid=222(ec2-user) gid=500(ec2-user) groups=500(ec2-user),10(wheel),48(apache)


[ec2-user@xxx ~]$ ls -la /var/www/html
total 176
drwxrwxr-x  6 apache apache  4096 Oct 24 00:44 .
drwxr-xr-x  3 apache apache  4096 Oct 23 22:51 ..
-rwxrwxr-x  1 apache apache   395 Jan  8  2012 index.php

If I try to edit or remove index.php I get "Permission denied".

I must be missing something obvious!! Please help!

If you need anymore info, please let me know.

  • 3 Contributors
  • 2 Replies
  • 245 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by CimmerianX

Dani AI

Generated

Likely cause and quick resolution: adding a user to a group updates /etc/group but does not change the groups that an already-logged-in shell uses. ’s output shows the account is listed in the apache group, but the live session probably hadn’t picked that up. A new login (or starting a new shell with the apache group) makes the group membership effective, and then the existing group-write bits on the webroot allow edits/deletes.

Core checks and quick fixes:

# show the shell's active groups
id
groups

# make the apache group active in the current shell without logging out
newgrp apache

# quick write test (create and remove a temp file in the webroot)
touch /var/www/html/.writetest && rm /var/www/html/.writetest

If permission is still denied after reloading group membership, look for other causes that can block writes even when UNIX perms look correct: ACLs, immutable attributes, SELinux, or a read-only mount. Useful diagnostics:

getfacl /var/www/html /var/www/html/index.php
lsattr /var/www/html /var/www/html/index.php
getenforce
mount | grep /var/www

Longer-term setup notes: keep files group-owned by the web-admin group (apache), avoid 777, and use SGID on directories so new files inherit the group (chmod g+s on directories). If multiple admins deploy, consider setting a shared umask (002) or using setfacl for per-user rules. This resolves the common case that and asked about: the session not inheriting the newly added group.

Member Avatar for rubberman

So, please share your solution... :-)

Member Avatar for CimmerianX

I'm kind of curious myself. What was the issue and resolution?

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.