mkdir() not working - php

My code
mkdir("/some/absolute/path",0777);
and
mkdir("relative/path", 0777);
is not working, safe mode is turned off, and I've even tried setting all of the parent folders to 777.
Any ideas?
EDIT: I do have error reporting turned on, in my frustration I've 777'd the whole path just to make sure that, that isn't the issue. It's gotta be something stupidly simple going on.
EDIT EDIT: Upvotes for everyone who responded with suggestions... But I'm not going to select an answer since this still isn't resolved, but then again I think this is going to be one of those ones left open forever.
EDIT x 3: So I have the most unsatisfactory resolution to this question ever... I started with a clean VM image, retried it and it works now. No joke.

Do all of the parent directories exist?
If not, you'll need to enable recursion (assuming PHP5 here):
mkdir('/path/to/your/dir',0777,true);
EDIT: Didn't see the hidden comment saying that every directory from var downward was set to world-writable, so I'm betting the directory path exists and the above won't be helpful. Sorry!

Are you trying to create those directories recursively, like you would do with mkdir -p on the command line? If so, specify true as the third parameter to mkdir.
And just to echo the previous suggestions, PLEASE specify the error messages you are getting. If you are not getting any, use this before your call: error_reporting(-1); // ALL messages and ini_set('display_errors', 'On');.

If anyone gets stuck with this problem.. there's one answer I can give you that I spend 2 hours on finding.. I tried with using a full path, and "../mydirectoryname".
Try using:
mkdir("./mydirectoryname", 0777, true);
Instead of..
mkdir("../mydirectoryname", 0777, true);

Have you tried with the shortest test possible?
mkdir('directory',0777);
If this does not work I would try creating with a standard CHMOD like 0755 (this is a totally random guess, maybe the server won't allow creating 0777 via PHP)
if this don't work I would say the server probably need different setup / php doesn' thave the writting right on folder, maybe you could ask your host provider?

I have similar problem and I found out, that I have no free space left on my drive. Check with command df (on linux) how full is your drive. It is possible that root is allowed to create files and folders in this situation, because he has pre-reserved space. If you run you script from command-line as root user - there is no error, but if your script is run by apache, then error occure.

For future references, the problem might come from the possibility that the directory where you're trying to create your new directory doesn't have enough permission.
For instance, your index directory might look like this:
index.php new_dirs_here
if new_dirs_here doesn't have enough permission then you can't create direcories inside.
To solve this, I'd use the command:
chmod 777 new_dirs_here
I'm not worrying about security now, Just trying to solve the immediate problem. You could of course look up a better permission settings, but the idea is that your new_dirs_here should have enough permissions.
Then, your mkdir() dunction should work just fine.
Good luck

Make sure the parent directories have correct write permissions, that was my problem

mkdir only creates one single directory when called without -p.
A directory in the path /usr/local/myfolder/ is missing, this is why you get the error. If you call mkdir -p, the missing path is created as well.
Another effect of using the -p option is that mkdir -p does not complain when the directory already exists. This is why this variant is frequently used in scripts.

chown www-data:www-data (address directory)

You're missing quotes around the path name parameter.

You must take the attribute in quotes:
mkdir('path/to/your/dir','0777');

Related

PHP Copy not copying

I have been searching for an answer everywhere all morning, and I can't seem to find one. Even on here, so please don't mark as a duplicate.
Basically, I am using php to make a dir and then copy a file to it:
mkdir('servers/'.$name.'/');
sleep(2);
copy("dummy/text.txt", "servers/".$name."/text.txt");
But that doesn't work. I even tried: copy("dummy/text.txt", "servers/$name/text.txt"); and copy('dummy/text.txt', 'servers/'.$name.'/text.txt');
Also, (for testing) I chmod the directory (whole thing, including sub folders) 0777 and chown www-data:www-data still not working.
Please help? Thanks!
you create the dir not where you want to copy the file afterwards.
mkdir("servers/".$name);
Also i recommend that before you ceate the folder, you check if it exists already:
if(!is_dir("servers/".$name)){
mkdir("servers/".$name);
}
Found it out! Before I created the script I made a typo when I made the directory myself. I did (on cli): sudo mkdir dummmy (3 "m" s) Then I made the scripts the correct spelling. Ugh, I have been wasting a full 3 and a half hours on that :P

PHP file_exists returns false but the file does exist

I have seen several similar questions, but no answer worked in my situation, except that it probably has something to do with permissions.
A PHP script served by Apache tells me unable to open database file.
When I print the path to that file, it returns a valid path, say DBPATH. The file does exist at that location; I gave it and its parent folder 777 rights; I gave them user:user access, where user is the sudoer that all script files belong to. I did the same to the whole htdocs/ folder, just in case.
When I print file_exists(DBPATH), it returns false. Is is most likely a matter of permissions, but I don't know what I should change for PHP to have access rights. I tried apache:apache, too. I cannot su apache (user not available).
My scripts are in htdocs/. DBFILE is somewhere out of it (I tried /tmp/test, all in 777, but no luck either).
No safe_mode, PHP 5.4 freshly installed, CentOS7.
Please someone give me a clue at least to help debug it.
Maybe such as: how can I check whether my file will be readable from apache/my php script, without running the script itself? How can I get the name of the user that is used to execute it?
Solved, more or less.
To debug I had the idea to move DBFILE to the same folder where the PHP script lives, and check it can find it - it did. Then I move DBFILE one folder after another in the tree to see where it stopped finding it.
It occurs that if only one of the folders in the whole path does not have execute rights for all users (xx5), the file cannot be found and file_exists returns false.
So the solution was to create another folder in a totally executable place (/var/www/data/ worked after chmod 755 data), and move the file there.
Do you use an absolute path or relative path?
Because file_exists() doesn't work with HTTP addresses (which is an absolute path). But you can enter the relative path.
I had the same problem and it fixed it. It was the same problem with unlink().
Exemple:
$file_relative_path = "./wp-content/uploads/fileDirectory/fileName.jpg";
if (file_exists($file_relative_path)) {
unlink($file_relative_path);
}
I had a similar problem and was able to solve it by the answer of JulienD:
If the execute flag of a directory in the file system (Linux) is not set, then PHP (still) scans this directory with glob or scandir. However, a subsequent check with file_exists() on this list of results, I wanted to find broken symbolic links, returned false!
So the solution was to set the Execute right for the directory, as mentioned by JulienD.

Specific php file not opening

hopefully someone can shed some light on my problem. I just reinstalled my OS (lubuntu 12.10) and have set up my local server. Everything seems to be working properly except for the one file I'm currently working on. When I try to run it in the browser, it downloads and/or gives a Server Error (HTTP Error 500).
I don't suppose it's an Apache or PHP problem since other files work just fine, but I don't think there's anything wrong with the code in the file in question.
What else could be causing this issue?
There is no need to "suppose" or devise "more than likely" cause or guess "what else".
HTTP Error 500 means there is something verbose in the server's error_log.
Just open it end get the exact explanation of the problem.
Please, do not take blind action, out of mere guess. You can make things worse.
This problem is more then likely caused by a permissions issue.
The Apache server runs as www-data:www-data. What this means is that it is possible to have some permission issues with files that were created by another user.
To solve this, you should either add your user to the www-data group and set the /var/www directory to inherit the group www-data, or you can use chown to change the ownership of all the files to be on the www-data group.
To keep security in your system, you should also make sure that all your files have a permission set of 660, meaning that the owner and anybody of the user group of the file can both read and write, but any other user will not be able to do anything with it.
If you have a php script that does run more than 30 seconds (default) you have to change value of max_execution_time by using ini_set function.

php file_put_contents function not working

Why would file_put_contents refuse to work for the following code?
$f = file_put_contents("files/r.js", "Some text here");
if ($f) print 1;
else print 0;
It could be a permission problem
Is the directory /files chmoded to 777? sometimes php won't allow you to access directories if they don't have enough permission. I don't know about blank errors though.
Try to see if it has enough permissions, if not, then set it to 777 and try it.
Are you using the full path on the filesystem or are you trying to use the URI? I think this PHP function expects you to give the path as the file is found on the filesystem.
Relative paths should be okay though.
You may need to make sure the file exists and that it's permissions are set to 777. Sometimes I've found that it's not enough to just have the directory permissions set to 777 but the file must also already exist.
It is because of SELINUX.
You can mark the folder as of type httpd_sys_rw_content_t with this command to enable writing to this folder.
semanage fcontext -a -t httpd_sys_rw_content_t '/files(/.*)?'; restorecon -RF '/files/'
We've experienced this, requiring a workaround (regardless of method, permissions and anything else mentioned here). When all other fixes failed, we have found it can be linked to restrictions created by SELinux.
If you’re using windows the following solution worked perfectly for me on Windows 10 running php 5.5.38
If you’re having this problem on Windows/IIS try the following:
Go to the Folder that you are trying to write to and right click it, then select properties.
Select the Security Tab
Click Edit
Click Add
Click Advanced
Click Find Now
From the list of User select IUSR and click OK
Click OK again.
The IUSR will be displayed in the top box labelled 'Group of User Names'
Select IUSR and grant necessary permissions in the 'Permissions for BATCH' list view.
Click Apply and then you are done.
The steps may be slightly different for different versions of windows. This also applies to ASP.NET though I think the users you add are the network users (NETWORK AND OR NETWORK SERVICE users) as well as the IUSR.

Why would file_put_contents() succeed but touch() fail?

I'm running a script that makes some changes to the contents of a file then resets its modification time to what it was before. Intermittently, I'll find the following errors in my log:
touch() [function.touch]: Utime
failed: Operation not permitted
This on the line immediately after a file_put_contents() call appears to have changed the contents of the file I tried to touch(). There are no errors associated with the file_put_contents() line.
Has anyone had this happen? Can anyone figure out what set of permissions would allow me to write a file but not change its modification time? I'm doing this on Linux.
This is a bug with PHP's touch command. Even if you have write permission to the file, it fails if PHP isn't also the "owner".
If you're using Apache and Linux, use this command on your server's console to make PHP the file's owner:
sudo chown www-data:www-data /YourPATH/YourFILE
Better still, update the entire folder containing files you want PHP to control:
sudo chown -R www-data:www-data /YourPATH/YourFOLDER
Side Note: Because PHP can write to the file, that means it must have user or group write permission. Since that's the case, touch should not behave this way. It seems like a bug.
It could be possible that the file gets created with wrong permissions. Try to chmod 777 the file just after the file_put_contents and then touch the file.
As rossoft says, PHP is probably not the owner of the file. But setting the permissions to 777 might not be the best solution. I'd preferr:
function touch_file($file) {
fclose(fopen($file, 'a'));
}
touch_file('/path/to/file');
Only recently, I've had a similar problem and I think I know the answer.
The actual purpose of touch() is to update the modification and access times of a file. Creating the file is just a side-effect.
If you're using Linux, but writing to an NTFS partition as you might with a dual-boot configuration, depending on how the partition is mounted, touch() might have problems changing the access time on files. The file will be created, but touch() will still fail because the underlying system returns an error status. The same thing can be observed from the command line where you'll get a "permission denied" message.
There doesn't seem to be any documentation regarding this in the man pages for mount, ntfs-3g, or touch (Linux command), but the problem is mentioned in the comments on the touch() PHP function page.
Tweaking mount options might provide a solution, but you're better off using is_writable() to check permissions and fopen() to create files.

Categories