October 19th, 2010, 09:17 AM
File_put_contents not working
I have a number of php scripts that use file_put_contents to create very basic text files.
These php scripts have been copied to a brand new dedicated server I am leasing and now they no longer seem to work.
Should I be checking permissions or php.ini or something else?
I am at a standstill with this and appreciate any points in the right direction.
October 19th, 2010, 09:30 AM
Are the folders that you are saving the files to writable? (Try to CHMOD the folder to 0755, and if that doesnt work, 777. It depends on the server setup.)
October 19th, 2010, 09:52 AM
Does it make sense that my old server had these files and folders at 0755 with no problem but this one seems to require 777?
Originally Posted by simshaun
Is there something I can change in my php.ini so that files that come from the old server will still work in this new environment?
Thanks in advance!
October 19th, 2010, 10:10 AM
Yes, since the server setup is different. Whether or not you need 755 or 777 is dependent on how Apache is setup and what modules you have installed.
Without getting too involved (I will if you ask), the folders on your new server are probably owned by a specific user (e.g. "johndoe"), whereas Apache is running as the user "nobody" or something similar. The easy way of allowing Apache to write data to the folder owned by johndoe is to chmod it to world writable (777).
October 19th, 2010, 10:18 AM
Feel free to get involved (or point me towards a link or article that does).
Should I be concerned about opening up my folders with a 777 permission?
Thanks for all your help so far!
October 19th, 2010, 11:12 AM
On a dedicated server not so much.
October 19th, 2010, 11:30 AM
Being on a dedicated server, it's less of a risk.
Every folder and file on a Linux system has an owner. You can see this by logging in using a decent FTP client (FileZilla) or by cd'ing to your webroot and running ls -l (lowercase L) through the shell.
When you create or upload files, they are owned by whatever user you are logged in as. When logged in via the FTP user johndoe, files are going to be owned by johndoe. If you create a folder via FTP, its going to be owned by johndoe.
This is where things start to branch based on how Apache is configured.
- In a basic Apache setup (no additional modules that affect security), Apache typically runs as a "nobody" user and in a "nobody" group. This is important to know if PHP is running as an Apache module because it means that any file uploaded through PHP is going to be owned by the "nobody" user.
When you login to FTP as "johndoe", you won't be able to change or delete these files, since they are set to 644 and you don't own them. All you would be able to do is read them (which is what the last 4 means). The files must be CHMOD'd by PHP to 777 (typically after being uploaded) in order for you to rename or delete them via FTP.
- PHP can be installed as a CGI module, rather than being ran as an Apache module. In this instance, PHP can be ran as its own user/group. In these situations, many hosts typically resort to an Apache module such as phpSuExec or suPHP. These modules allow PHP to run with the same permissions as the hosting account.
In this manner, any files uploaded via PHP are owned by johndoe, the same as if you uploaded them yourself via PHP. At the same time, it also means that your files and directories no longer have to be world writable for PHP to write to them.
In fact, modules such as suPHP prohibit files/folders that are world writable (777). It will throw a 500 Internal Server error when you try to execute them.
I'm sure I'm missing a lot, but that should be enough to cover what you're wanting to know (I hope.)