Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By johnhelen on
Hi
When I install Drupal, I have to set up the files folder and I have to set it to writeable. So I set it to chmod 777 then I can upload my files into this folder.
My question is, if I set so in Linux, other people can access, delete files in this folder as it is 777 permission. If I change this to 755, I cannot upload files anymore. How I can fix this problem
Many thanks
Comments
If you have root or sudo
If you have root or sudo access to the server, you can chown the files in there to the web server's user instead of your FTP user (usually, "apache" or "www-data"). That'll allow Drupal to modify them without having them 777'ed.
Otherwise, you're SOL.
Umm, what is SOL ?? Life is
Umm, what is SOL ??
Life is tough when people only talk in abbrevs :-)
=-=
SOL = Crap Outta Luck , Though think of the S word for Crap
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
I use WS_FTP to chmod my
I use WS_FTP to chmod my files. There is one problem, however. I can change the chmod numbers all right, but next time when I access them with WS_FTP, they always show "644" - even though I had set them to something else.
So, I'm looking for a program (not Linux) which shows me the chmod numbers... Any ideas?
[EDIT] OK, I installed SmartFTP, which sets and shows the Chmod numbers.
I'm a bit confused here. If
I'm a bit confused here. If my /files folder is set to 777, does that really mean that others ('the entire world') can delete the files over there??? They would at least need FTP access to my site and the /files folder, no? Or does "777" automatically mean: "waiting to be deleted by just anyone"???
A "7" in Linux file
A "7" in Linux file permissions corresponds to "read, write, and execute" privileges. The first digit is your user permissions, the second digit is the group's permissions, and the third digit is the permissions for all other users.
So, 777 effectively means "let anyone who has an account on this server do anything they want to this file". Yes, they'll need FTP access, so if it's a dedicated box the risk isn't huge... but on a shared server there could be hundreds or thousands of people with access.
Thank you very much,
Thank you very much, cessjayoz
I had the same problem -
I had the same problem - what I did is added 'apache' user to the group and set 775 permission. Is that a valid solution? Is there only one 'apache' user so that i don't have to worry about someone messing up with my files?
The chmod command changes
The chmod command changes the permissions on files and folders.
Most people use the 3-digit Hex value, where the first digit is for owner, second for group, and third for other/all. Hex values are as follows...
Read = 4
Write Access = 2
Execute Access = 1
Knowing this, you can make up any combination you want or need.
For read, write, and execute access the Hex value would be 7. (because 4 + 2 + 1 = 7)
For read, write access only the Hex value would be 6. (because 4 + 2 = 6)
For read and execute access only the Hex value would be 5. (because 4 + 1 = 5)
(et al...there are other Hex values but those are the most common)
You can apply those Hex values to the owner, group, and other/all.
775 gives rwx to the owner (first 7), rwx for the group (second 7), and rx for other/all (third 5).
The chown command changes the user (and in the example I will give for group as well).
chown blah:blah filename (or folder).
In the above example I changed the owner to "blah" and group to "blah".
You can also throw in the -R switch to recursively change permissions and/or ownerships throughout the whole sub-directory tree.
If you understand, things are just as they are. If you do not understand, things are just as they are. ~ Zen Proverb
yeah
"Group" is my preferred approach.
I usually add my local developers (me and friends) to the 'www-data' group (or 'apache' if equivalent).
Then, with the files dir set to g+rws (Group read-write, sticky) and owned by that group, I have few problems editing the same files via either filesystem or web interface.
(or something)
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Hm...but how do I add the
Hm...but how do I add the user to the 'apache' group?
The problem is that I can't change the files drupal makes because it makes them as 'apache' user and within 'apache' group....So I guess I should add myself to the 'apache' group, right?
can you pls explain in steps how I can do that?
thanks!
read up on server admin
Of course this depends on you having root or user admin ability. Without it any solution is sub-optimal.
The 'sticky' bit is supposed to mean that any subsequent new files use the same sort of umask as the containing folder, but I think it can be a bit flaky. I think it's doing the job for me.
You can also do the reverse, adding the apache user to your own your 'staff', 'users' or 'developers' group ... but that's not quite right strategically.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
You can also do the reverse,
but this is exactly what I asked my host to do for me since the directory files (created by drupal as 'apache' user) was not originally writable to drupal with 775 permission. When 'apache' was added to the group the problem was solved.
How could I have done it otherwise?
thanks!
It's not right (IMO)
It's not right (IMO) strategically in that in many environments you would want your user (or user group) to have access to things that you don't want the web daemon to have access to. Just for security best-practices etc, it's best that the web daemon is in its own little box.
Your account, as a slightly higher entity should be able to manipulate the webs files, but it can't do the same to yours unless you give it permission. See?
Importantly, we want only you to write to the code files, and both you and the daemon to write to the files dir.
However, if you're on a remote host and don't actually use your account for anything but messing with web files, the crossover is almost complete.
It may in fact be easier (as your web host has done) to make the web daemon MORE powerful than you so that you don't get hung up on the 'remember to give it permissions' step. I guess it also means that you as an individual can't mess with other accountholders r/w content.
Easier ... but it also means that your webserver may now have the ability to rewrite/overwrite its own code. It means that any compromise within the system may do very bad things. Drupal can now be persuaded to shoot itself in the head, or worse. When before you owned the core files and the webserver could only read them, damage was limited. Now the apache daemon (which probably includes the instances of other sites on your shared machine - other website users) may write what it likes, as it's in a group that has write permissions to those files.
I would be uncomfortable with this on a shared system. It can still be mostly secured if your umask is correct (you can still turn off 'group' access to your files) but you'd better check.
There are dozens of configurations that may work for different hosts. I just described my preference as it makes sense to me - who has several trusted developers pushing files at one apache process. There are other valid approaches to this.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
hm..the command that worked
hm..the command that worked for me was :
usermod -a -G apache usernamethanks for your detailed post!