Workaround for when host does not allow 777 to be set?[Resolved ]
I'd like to install Vanilla 2.2 on Sourceforge's Project Web service, however they do not allow chmod 777 to be set period. They do allow 775. Is there any way I can work around this limitation so Vanilla can install?
Best Answers
-
tgp1994 New
Edit: Looks like it decided to start working! I have no idea what's changed, but it might have been an issue with my browser caching the error page and not refreshing properly? Oh well, looks like the problem is solved. Sorry everyone!
5 -
River MVP
You have it all sorted out, but for users who don't understand file ownership and don't realize it is a fundamental component of permissions.
It all depends on the GROUP ID or USER ID.
this image appears during set up because the setup determines the folder is not writeable by the web-server.
If the file or folder is assigned an improper "user" or "group" and web server php tries to write to the folder via vanilla installation setup program and it can't write to file it automatically presents an error message with instructions to set permissions to 777. This is a "blanket solution" provided to solve the problem (but often not the best), because many people may not understand file ownership and don't realize you need to know the group and owner of the file AS well as the process that is executing the web server php. Saying set something to 777 or 775 or 644 is irrelevant if you don't know the owner and group names. The third number is Other and means anyone --7 is writeable for everyone. -7- is writeable for the group 7-- is writeable for the owner. Until the owner id or group id is known only half the information is known and the blanket solution (other set as 7) is the easy way out.
The crux of this permission issue is how your server is configured. The username you use to FTP or SSH into your server is most likely not the username used by the server application itself to serve pages.
7 7 7
user group other
r+w+x r+w+x r+w+x
4+2+1 4+2+1 4+2+1 = 777Apache server is often 'owned' by the www-data or nobody user accounts.
here is how the setup controller does things.
tests the Reading and writing of the folders.
// Make sure the appropriate folders are writable. $ProblemDirectories = array(); if (!is_readable(PATH_CONF) || !IsWritable(PATH_CONF)) { $ProblemDirectories[] = PATH_CONF; } if (!is_readable(PATH_UPLOADS) || !IsWritable(PATH_UPLOADS)) { $ProblemDirectories[] = PATH_UPLOADS; } if (!is_readable(PATH_CACHE) || !IsWritable(PATH_CACHE)) { $ProblemDirectories[] = PATH_CACHE; } if (count($ProblemDirectories) > 0) { $PermissionProblem = true; $PermissionError = t( 'Some folders don\'t have correct permissions.', '<p>Some of your folders do not have the correct permissions.</p><p>Using your ftp client, or via command line, make sure that the following permissions are set for your vanilla installation:</p>' ); $PermissionHelp = '<pre>chmod -R 777 '.implode("\nchmod -R 777 ", $ProblemDirectories).'</pre>'; $this->Form->addError($PermissionError.$PermissionHelp); } // Make sure the config folder is writable. if (!$PermissionProblem) { $ConfigFile = Gdn::config()->DefaultPath(); if (file_exists($ConfigFile)) { // Make sure the config file is writable. if (!is_readable($ConfigFile) || !IsWritable($ConfigFile)) { $this->Form->addError(sprintf(t('Your configuration file does not have the correct permissions. PHP needs to be able to read and write to this file: <code>%s</code>'), $ConfigFile)); $PermissionProblem = true; } } else { // Make sure the config file can be created. if (!is_writeable(dirname($ConfigFile))) { $this->Form->addError(sprintf(t('Your configuration file cannot be created. PHP needs to be able to create this file: <code>%s</code>'), $ConfigFile)); $PermissionProblem = true; } } } // Make sure the cache folder is writable if (!$PermissionProblem) { if (!file_exists(PATH_CACHE.'/Smarty')) { mkdir(PATH_CACHE.'/Smarty'); } if (!file_exists(PATH_CACHE.'/Smarty/cache')) { mkdir(PATH_CACHE.'/Smarty/cache'); } if (!file_exists(PATH_CACHE.'/Smarty/compile')) { mkdir(PATH_CACHE.'/Smarty/compile'); } } return $this->Form->errorCount() == 0 ? true : false;
Bottom line if you set you folders as 775 but the folder is not the same group or owner as the apache (server) process it will not be writeable. So there are two solutions, one better than the other adjust the owner or group id or expand the permissions to other. Some servers you have no control over certain things due to the host and force you to expand the permissions of 777 to work. But ideally setting the user or group ids of the files and folders to match the web server process is he ideal way to go. Setting other (or world) to be writeable is generally not necessary (nor a good idea) for properly setup servers with proper ownership.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
11
Answers
@tgp1994
Are you sure you need 777?
I thought 775 would be enough.
Heh, am I sure? Vanilla sure seems to think so : I thought 775 would be enough too, but not according to the installer. I just want to know if I can work around it. Directories are already set to 775.
You can make the conf folder 755 and the config.php 775 as well as the uploads 775 and the cache
If you can't do that, I suggest you get a different host because all of the software like Vanilla and Wordpress etc require those permissions for configuration files.
Someone else came around here recently asking the same thing. He ended up getting another host.
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
OK, I have no problem setting permissions to 755/775 so Vanilla will still work then. How can I bypass this error message in the installer? Apparently it will not proceed unless it thinks the directories are set to 777.
How did you install Vanilla ? Please let us know the url of where the forum is supposed to be installed.
The only option is to look at your files and how they are installed. you would need to give us your filezilla login info via private message to remotely see what is what is going on.
Tell your host to set those folders to 777 temporarily until you finish the setup and then return them to 775 etc.
The thing is that those folders need to be writable. So that the config.php gets created and populated.
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
I installed it the normal way - downloaded Vanilla 2.2.1 release, uploaded to host, unzipped, and opened index.php. It seems to me that the installer expects permissions to be 777. I'm thinking at this point I'll just modify the installer the script so it doesn't require such generous permissions. The folders are writable, I can say that for sure.
Edit: Looks like it decided to start working! I have no idea what's changed, but it might have been an issue with my browser caching the error page and not refreshing properly? Oh well, looks like the problem is solved. Sorry everyone!
You have it all sorted out, but for users who don't understand file ownership and don't realize it is a fundamental component of permissions.
It all depends on the GROUP ID or USER ID.
this image appears during set up because the setup determines the folder is not writeable by the web-server.
If the file or folder is assigned an improper "user" or "group" and web server php tries to write to the folder via vanilla installation setup program and it can't write to file it automatically presents an error message with instructions to set permissions to 777. This is a "blanket solution" provided to solve the problem (but often not the best), because many people may not understand file ownership and don't realize you need to know the group and owner of the file AS well as the process that is executing the web server php. Saying set something to 777 or 775 or 644 is irrelevant if you don't know the owner and group names. The third number is Other and means anyone --7 is writeable for everyone. -7- is writeable for the group 7-- is writeable for the owner. Until the owner id or group id is known only half the information is known and the blanket solution (other set as 7) is the easy way out.
The crux of this permission issue is how your server is configured. The username you use to FTP or SSH into your server is most likely not the username used by the server application itself to serve pages.
7 7 7
user group other
r+w+x r+w+x r+w+x
4+2+1 4+2+1 4+2+1 = 777
Apache server is often 'owned' by the www-data or nobody user accounts.
here is how the setup controller does things.
tests the Reading and writing of the folders.
Bottom line if you set you folders as 775 but the folder is not the same group or owner as the apache (server) process it will not be writeable. So there are two solutions, one better than the other adjust the owner or group id or expand the permissions to other. Some servers you have no control over certain things due to the host and force you to expand the permissions of 777 to work. But ideally setting the user or group ids of the files and folders to match the web server process is he ideal way to go. Setting other (or world) to be writeable is generally not necessary (nor a good idea) for properly setup servers with proper ownership.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
Very nice explanation, thank you!
the only reason why any ever set 777 is poorly implemented generic cheap hosts, with no ability to set ownership.
777 is just bad file management and laziness.
The problem is people don't understand it is not just permission it is about ownership and groups.
I don't even like when people use web applications manage their files, that is the tail wagging the dog.
grep is your friend.