Necessary folder permissions

[polyfragmented]

Hi guys,

I can't find a table or general info on which folders need what permission. Searched the wiki and here in the forum. Have I overlooked it? Feel free to hammer me with a "RTFM <LINK>" then. I read a fragment here and there, but find it difficult to piece the info together. Some authoritative info would be awesome.

We're (Connie and I) are in the process of setting up a German site for GS and are running into permissions problems with webhoster all-inkl.com. 755 doesn't seem to work here for the data folder for instance. Had to pump up the rights to 777 to be able to successfully edit components in the backend. Theme files cannot be edited in the backend, because the respective file cannot be opened. I'm not comfortable with 777-ing everything and I'm lacking some knowledge in that respect as well, so I'd like to learn.

Help? \o/

[hameau]

I would say that it depends on how your hosting service sets up the account and they should know what permissions are required for the webserver to read and write files. As far as I know, only the webserver needs to read or write any of the GetSimple files and folders. There should never be a need for permissions of 0777 if the ownership is set correctly.

What is the owner of the files after you transfer them (by ftp?)? What user is apache/php running as? If you chown the files to the webserver user you won't need open permissions.

For example, with my hosting service (ovh.com) php and ftp each run as the same user, so recommended permissions are 0705 (folder) and 0644 (files). (Indeed, higher permissions than 0755 are forbidden and will result in a server error.)

On my own test server, running Debian, provided that all the files are chowned www-data:www-data, the 0755 (folder) and 0644 (file) works fine: tighter permissions would also work, but I haven't experimented.

[Connie]

it is never really clearly defined by the hosters who is the owner of the files in which situation unfortunately how should we know?

I uploaded as ftp-user to the server, installed as usual in the browser ..

I found in their http://all-inkl.com/wichtig/faq/#faq_datenbank

files, created by a php-script, automatically belong to the owner of the webserver 'wwwrun' or 'www-data'

this owner can be changed (after the installation)to the same user as the ftp-user in their Userpanel, but this is not very userfriendly in my opinion, as this brings problems again if you have more than one FTP-user
(and they mention that it will need more up to 15 minutes time ...

oh holy cow! I always thought that all-inkl.com is a good provider, but this seems very uncomfortable to me.

So Thorsten and I will never be able to collaborate on this installation with satisfying user-rights.

[polyfragmented]

I'll contact my hoster for clarification.

[polyfragmented]

Got a reply from my hoster which I'll try on a testinstall now.

Edit: Alright. The solution is to switch to PHP's CGI version in .htaccess

Code:

AddHandler php[version]-cgi .php

which runs files as the main FTP user in the webspace account. So, remote editing and uploading files doesn't interfere with script permissions as before. All contributors have to use the same FTP user, namely the main user, though.

I ran a testinstall which worked having folders still at 755 and files at 644 (except /backup/+ and /data/+ which need 777)

PS Thanks for your info, hameau!

[hameau]

Backup and data files are written by the web server (apache/php for you?). Most likely, those processes are running as your ftp user. You should be able to see the user and group numbers in your ftp client. I would say that it's worth making some effort to avoid permissions of 0777.

If I understand the all-inkl.com FAQ correctly, you have ssh access so you can find the owner details more easily or manipulate ownership and permissions from the shell.

[polyfragmented]

Backup and data files are written by the web server (apache/php for you?). Most likely, those processes are running as your ftp user. You should be able to see the user and group numbers in your ftp client. I would say that it's worth making some effort to avoid permissions of 0777.

Yeah, Apache+PHP. As I wrote in the solution above, I have to use the CGI/FTP user "workaround" in order to avoid using CHMOD 777 on editable files. If I don't use it, I can't edit files from the backend.

GS is not the only system which bumps into this obstacle with all-inkl, e.g. Contao CMS provides a special mode which edits/uploads files as the FTP user.

You're right, using 777 should be avoided, yet GS' install routine suggests it for /backup/ and /data/ if the needed folders aren't writable. Have you CHMODed those folders differently?

[hameau]

You're right, using 777 should be avoided, yet GS' install routine suggests it for /backup/ and /data/ if the needed folders aren't writable. Have you CHMODed those folders differently?

I do have an issue with suggesting permissions of 0777, but there isn't a single solution for everyone, of course.

On my hosting service (ovh.com) I followed their guide and set folders to 0705, files to 0644 and everything works as expected, including data and backups, reading writing and deleting, editing theme files, all from the admin backend.

Would you like a referrer code ? :roflol: Just kidding, sorry, I couldn't resist.

All the files that I uploaded appear with uid of my account and the gid is 'users'. Files that GS generates (e.g., site archives for testing) also have the same uid and gid. The webserver processes are apparently running as my user id, so everything Just Works. (This has also been my experience with other software running on this host, so I'm just confirming my expectations.)

One interesting point, the GS admin website healthcheck is full of errors, as it doesn't consider folder permissions of 0705 as being writeable! Of course, they are writeable to the owner.

[polyfragmented]

Would you like a referrer code ? :roflol: Just kidding, sorry, I couldn't resist.

Haha, ^^ I'm going to check them out. Edit: too bad, all in French

Thanks for the info on your set-up.

[hameau]

... too bad, all in French

... ovh.de