What has me confused is why a directory or part of my Drupal site to suddenly return the message of "Forbidden" - that I, as first use, cannot access various parts of the site in the admin area. I changed the permission on the default/sites/files directory to 777. That probably is giving to too much access to everyone. However, it was only after doing that, that I got a message of Forbidden - that I don't have access to various parts of the admin area. I am the first user.
I changed the permissions on this directory because when I tried to update some modules, I got an error that file could not be created.
I have cpanel/whm on a dedicated vps server. So, one issue is how to find out what the user and group ownership should be on a server that hosts various domains through cpanel. It appears that for other accounts have user:owner permissions that match the account name. I am not sure if the default group:owner should remain as www-data:www-data for example, on Ubuntu or if cpanel/whm says, "make the apache group and user equal to the account name."
Thanks in advance for any help,
Bruce
First of all, I'm going to assume you're talking about Drupal 7, but really, there's little difference in this case.
Try reading about permissions here
Its very simple that the folder should have user:user ownership and correct permissions with folders having 755 permissions respectively. The server might be running on suphp hence you cannot have wrong user with wrong permissions.
Related
I'm new to WHM, cPanel, and CentOS.
I install WHM then create an account for domain app.example.com and user peter
I point the domain name to right IP address but when I run my website app.example.com I got HTTP ERROR 500
Via SSH I log into the server and I find my previous uploaded code into
/home/peter/public_html
Then I run command sudo chown -R peter:peter /home/peter/public_html
and when I look at folders permission and owner they looks like:
I think my HTTP ERROR 500 is about user permission.
Can please help me to add right privileges to a user or what I need to do to my public_html folder be visible to the world (at browser).
What I need to do?
The best thing to know if it's a permissions problem, a bug in the programming of the web application or to see what really happens, is that you look at the log file of the web server (apache, nginx, the one you use). The log will give you more clues. Could you copy the log output when the error occurs?
It seems some required extensions were not activate or had been removed from your VPS. You should check and install/activate them. Then you can test your website again.
P.S: Sorry for my bad english
I have looked around a great deal on the Drupal forum and elsewhere but I cannot yet resolve this.
I have had to reinstall a large, fully functional site (Drupal 7.18) onto a new server. This has gone very smoothly. However, I do not seem to be able to set permissions for my sites/default/files directory in a manner that keeps it accessible and safe when browsing using the IMCE file browser.
Usually I set sites/default/files (and subdirectories within it) as 755, with files within these directories as 664. This works well on many other Drupal 7 sites I have built.
HOWEVER in this case, with these permissions I get the message "Unable to get a working directory for the file browser".
Only by setting directory permissions as 777 can I browse the files in these directories using IMCE - and I know that is really bad practice on shared hosting.
Please can someone advise on troubleshooting this? I have spent hours but I am getting nowhere.
I wonder if the ownership of the files and directories themselves is wrong. If they are wrong, can anyone direct me to step-by-step instructions for changing them?
Examining the 'problem' files and directories using FireFTP, I see
that both user and group names are the same as the FTP username that
was given me by my web host.
Looking at another Drupal site that works properly, I see that files
and directories in sites/default/files are set to user 531/group 528.
Thanks in anticipation! I am running D7.18 on PHP 5.2.10 with extensions enabled. Everything else seems to be working very well indeed. However, I am not sure I have the Apache or Linux skills needed to resolve this, or even to ask my hosts the correct questions ...
755 basically means that only the owner of the files can modify them, so you could try changing the directory permissions to 775 so that the owner and group can modify.
If you are using shared hosting I suggest you ask your hosting provider to help as they will have a better understanding of the users and groups on the server.
Cheers
I am new to Joomla and have been given the task of supporting a site that was created in Joomla 1.5.25. They keep getting errors that files are not writable. They also can't add or delete anything to and from the media manager even in a Super Administrator account. I was able to override these errors with changing folder permissions from 755 (Joomla's recommended permission set) to 777, but was wondering if there is a better way of going about this (I don't want to leave a security hole on their site with the 777 permission set). From what I have read through my research is Joomla permissions requirements can vary based on your hosting company, so I want to get other peoples input before I give my hosting company a call.
On a side note, is there a way of getting the error messages to display longer then 2 seconds?
Why don't you try changing the permissions only to the folders that are written to temporarily? Another solution is to find out under which user apache is running and make sure that user is the owner or at least in a group that owns your Joomla! directory.
Obviously I am very new, so please bear with me.
I installed Kohana Framework in my localhost. To do is so we have to set two specific folders with write permissions to all. "chmod 666" is suggested. (here)
The remaining directories are set to 755.
My question is more directed to Apache.
Will the use of "chmod 666" create a vulnerability in a webserver?
What exacly means "write access for everyone"?
Many thanks in advance!
666 is almost always a really bad idea. The web site where you read that needs a good flogging.
"Write access for everyone" means that anyone with a user account on your system can write to that directory.
These rights are only for your current server, so if you are the only one with access to a user account on your machine you should be pretty safe. Write access for everyone means everyone with a user account on your machine has the right to write. Please note that 3rd party software (like apache) can have it's own user as well and this could be compromised if there's a exploit in that software. This way someone from the outside could gain access to that folder. It's a common practice to only give rights to users that really need access.
Note: On a normal Windows machine (don't know if this is still true with Windows 7 though) everyone has access to everyone's files. So this is just another security measure.
I'm running apache and my php site uploads images to the server. should apache upload dir have 777 permissions or belong to www-data user? How would this affect backing things up?
I think read + write permission is enough. read for backup, write for upload. It seems that no one ever need to execute anything.
And you should only grant permissions to who really need them. For example, grant write permission to www-data. And if you use another-user to do back up, only grant read permission to another-user.
You'd better avoid using 777
That depends on what you need from it. You should always use the most restrictive permissions that will let you do what you need.
Read the man page for chmod(1) to learn what the various permission bits mean. And maybe provide some more detail about your situation, so someone can provide a specific answer for you.
First and foremost the apache server needs to run as a non-privileged user. Second the upload directory should only need 600 as the permission (rw) iirc. This will allow the user that is running apache to write to that directory. The practical attack against a web server is to trick it into writing to a directory and having it execute the code that is placed there.