I tried to run this command:
php -r "touch('/mnt/my_drive/test.txt', 1600981328);"
I got this error:
PHP Warning: touch(): Utime failed: Operation not permitted in Command line code on line 1
If I run it with sudo, I don't get the error.
/mnt/my_drive is an NTFS drive. The mount was created in fsab with umask=000, so I have no idea, why do I get permission error.
Please do not mark this as a duplicate, because the similar questions have these answers:
Check the permissions: It should be right because of umask=000
Run composer/php in elevated mode: I would like to avoid running the webserver as admin
Modify some library files in vendor: I get this error even in command line, as my example shows
Don't use ntfs: It is not my choice
This may happen when the user PHP runs as isn't the owner of the cache files. Checkout this link Utime failed: Operation not permitted
Your code worked perfectly on my machine with php7.4 and ntfs mounted with:
/dev/sdaX on /mnt/tmp type fuseblk rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
Are you sure the directory you are trying to do this in allows you to create files? Does the directory exist?
If you can create normal files without setting the time parameter it might have something to do with ntfs or fuse mounting it.
In this case:
Try to run the php command in strace to see what actually fails, that should help nail down the error.
EDIT: Also the umask should not matter in this case, what matter are the permissions of the directories that contain the file.
Updating file modification time fails unless issued by the owner. Try to clear the cache files and recreate them with the PHP user as the owner.
It is never assumed a good point to change modification times, unless there is a need to file something in with others. It's hasty and shows no function to it. The only thing i can tell you is that you have to own the file, you may need root, just to access these permissions and that with sudo you can do anything. So you've no hope of this. I hope that can bring you to believe in some other way of a file system breakdown for your clients.
I've installed Reportico in /reportico under my website root. I set permissions for the folders template_c, projects and projects/admin to READ_&_EXECUTE, LIST_FOLDER_CONTENTS, READ, and WRITE for the user IIS_IUSRS. I've had PHP 5.3.28 running for months with the PDO extension working just fine, so no problems there.
When I browse to:
http://mywebsite/reportico/index.php
...it immediate forwards to:
http://mywebsite/reportico/run.php?project=admin&execute_mode=ADMIN&clear_session=1
...and I get a blank white screen.
I looked in the PHP logs and found this:
[27-Apr-2015 09:06:19 America/Tegucigalpa] PHP Warning: include(templates_c\%%62^620^6206D997%%admin.tpl.php): failed to open stream: No such file or directory in D:\inetpub\inventronicsusa\reportico\smarty\libs\Smarty.class.php on line 1256
[27-Apr-2015 09:06:19 America/Tegucigalpa] PHP Warning: include(): Failed opening 'templates_c\%%62^620^6206D997%%admin.tpl.php' for inclusion (include_path='.;C:\php\pear') in D:\inetpub\inventronicsusa\reportico\smarty\libs\Smarty.class.php on line 1256
This is my first attempt to run Reportico. Any idea what I'm doing wrong?
Peter Deed, the author of the software, was very helpful; he helped me find the answer.
While the web site says:
...ensure that the following files and folders have write permission:-
templates_c
projects - where you will create report suites
projects/admin - for storing the Reportico admin configuration
...just setting Read/Write permission for them is not enough. The software needs the ability to delete from these folders. So, in IIS, that means you have to give it Modify permission in addition to the Read/Write permissions mentioned above.
Hope that helps someone down the line.
What's problem in this code :
$handle = fopen("c:\DIGIPROG\welcome.txt", "rt");
OR
Something problem with another?
I set DIGIPROG folder Full access to everyone but still found error like this :
Warning: fopen(c:\DIGIPROG\welcome.txt): failed to open stream: No such file or directory in C:\xampp\htdocs\digi\test.php on line 1
Then, I tried to open the address directly from run : c:\DIGIPROG\welcome.txt
and it's opened.
My question, is it possible to read using fopen in folder on windows OS ?
Please help with example :)
Thanks
thats surely because the USER running your php executable has no read access to that path.
is a webservice running the php.exe process ? if so, what is the user (use your taskbar) surely it is SYSTEM (by default).
are you running the php script by hand ? then, your user (that used when you login on windows) must have READ permissions in that directory.
in both cases, right click the folder, go to security tab, add read permission to the SYSTEM user (or your user). To make a test only tell ALL USERS have read permission, remember to remove this entry later.
I'm using move_uploaded_file() to upload images to the server, however it gives the usual error of:
Warning: move_uploaded_file(upload/file.png) [function.move-uploaded-file]:
failed to open stream: No such file or directory in
/home/newuser/public_html/model/account.class.php on line 39
Warning: move_uploaded_file() [function.move-uploaded-file]: Unable to move
'/tmp/phpuLkUgE' to 'upload/file.png' in
/home/newuser/public_html/model/account.class.php on line 39
This is not permission based as I have set the folder to 777 with root access and ls -l displays it correctly as this.
755 /home/newuser/public_html/model
755 /home/newuser/public_html/model/account.class.php
777 /home/newuser/public_html/upload
PHP Line
move_uploaded_file($_FILES["photo"]["tmp_name"], "../upload/file.png");
The problem I think is down to the Owner/Group setting being configured incorrectly .. a while back I had all of my sites as subdomains in one account:
/home/olduser/public_html/subdomains/index.html
I then changed this and created a new user account to manage a separate website easier and just moved the files across ...
/home/olduser/public_html/subdomains
/home/newuser/public_html/index.html
The new folders in /home/newuser are now owned and grouped as newuser newuser but I think php may be running as nobody olduser so this could be causing the issue?
What can I try to fix this?
Permissions to a particular file / directory don't just apply on the directory itself, but on the whole path leading up to it.
Example:
/home/ - needs 'x' permission (execute)
/home/newuser/ - needs 'x' permission
/home/newuser/public_html/ - needs 'x' permission
/home/newuser/public_html/avatar/ - needs 'wx' permission (execute + write)
It was kind of touched on indirectly in Silver89's feedback under Jack's Answer, but not outright stated - so I wanted to provide an answer to what helped me with this issue which had me scratching my head for a long time. ;)
The best approach that I have found for the destination of move_uploaded_file() is to use the full absolute path. It can vary based on whether you are on a Unix\Linux server or Windows server, but this should give you the basic idea.
On my Unix server at work, you cannot use "../anything" but have to use the full absolute internal file path of /var/www/html/uploads/imagename.jpg.
So that is why your last test worked for you, Silver89 - because your server was probably trying to upload the image to http://yourservername.com/upload/file.png instead of http://www.yourservername.com/yoursubfolder/upload/file.png. It probably threw out the "../" part altogether and that folder didn't exist on the server.
You can find out what that full path name is by logging onto the server (terminal/ssh etc.) and issuing the 'pwd' command or by using PHP code and echoing the getcwd() command in a stripped php file in the folder where your images will go.
This site is helpful in figuring this out based on your server using different PHP Server Config Checking Functions - See the table midway down. You can simply echo these out to the screen such as:
echo $_SERVER["SCRIPT_FILENAME"].
This was a tough one for me so I hope this makes it a little easier for the next person to find - even if this is 8 months old. ;)
when I uploaded the script to the server I got this error
Warning: Unknown: open(/tmp/sess_58f54ee6a828f04116c2ed97664497b2, O_RDWR) failed: Permission denied (13) in Unknown on line 0
Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0
The error appeared when I call session_start(), although I set the permission of /tmp folder to 777.
Change session path where you can write data or contact server administrator about /tmp problem
http://php.net/manual/en/function.session-save-path.php
you will need to change your session.save_path php.ini directive
You can do that using session_save_path
If you have SSH access, here is how to correct the permission and ownership
sudo chown -R NAME_OF_USER /tmp
Replace NAME_OF_USER by the user under which runs php. You can find it by simply putting these lines in a php file:
$processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];
exit;
Check that you're not running into diskspace issues. If all the permissions are correct (and 777 ought to do it for you), then you might still get this error (for some versions of PHP and Apache) if there isn't enough space to write to the disk.
I had this problem in the following situation:
I filled some session vars with PHP
While the session was still active, I changed from PHP 5.4 to 5.3 on my host.
Reloading the page gave the error, described above.
Reset the PHP version to 5.4 again.
Used session_unset(); and session_destroy(); to clean the current session.
Changed the PHP version back to 5.3.
Now it works again.
Conclusion: For an irrelevant reason I had to change my PHP version, and while switching with sessions alive, the sessions get corrupted.
I realize that this is an old post, however I just ran into this problem, and found an easy solution.
For me, the issue was happening with one of my websites deployed locally. I hadn't tried accessing the websites using other browsers, but it was happening every time I tried to access this site via Chrome. I decided to go into the Chrome developer tools, under the application tab -- and clicking "Clear Storage". Voila -- everything is working like magic again.
Hope this helps someone else!
Additionally, you may want to use ini_set('session.save_path', '/dir/here'); assuming you have access to this function. The other ways suggested are valid.
I've just had exactly the same problem with one of my PHP scripts and I was like what did I break 'cos it worked perfectly the day before and I'm running it from my own local Puppy Linux machine so it's not even a host or anything.
The only thing I'd been doing before that was trying to get Java to work in the web browser, so some how I'd managed to get Java to work but broke PHP - oops!
Anyway I did remember that whilst trying to get Java to work I had deleted the contents of the /tmp folder to wipe anything out that may be causing a problem (it actually turned out with Java I was using the old plugin oij with the new Firefox)
To solve this problem I opened up Rox File Manager, went to the / folder and right clicked on the tmp folder -> Mount Point 'tmp' and clicked properties.
I noticed the permissions were set as Owner - Read, Write, Exec, but Group and World were only set at Read and Exec and not Write. I put a tick in Write for both Group and World and now PHP works fine again.
I don't know at what point the permissions for tmp must have changed but for PHP to use them it must be set to have Write permissions.
Add following line
ini_set('session.save_path', getcwd() . '/tmp');
before
session_start();
if you are using Apache web server, the quick fix is to go to your command line and type:
open /etc/apache2/
then from the window opened, open the file called httpd.conf and search for User or Group change these 2 lines to:
User _www
Group _www
This is because you want your server to have permission to your systems directories, especially you want to change the User or you can leave your Group to either staff or admin.
I had the same problem of permission, but on /var/lib/php/session/.
To fix it, I deleted the file and restarted php-fpm.
rm -rf /var/lib/php/session/sess_p930fh0ejjkeeiaes3l4395q96
sudo service php5.6-fpm restart
Now all works well.
For me the problem seems to be a WHM bug!
I have a bunch of add on domains and all work fine but with a subdomain it brings this error.
Strange thing but if I use the full URL with the main domain it works fine:
main-domain.com/my.subdomain.com
If I use the subdomain directly it brings "Permission denied (13)":
my.subdomain.com
The thing is all addon domains root is:
/home/xx/
But for my subdomain, don't know why, the root is: (I shouldn't have access to that dir)
/
So it´s really trying to reach: /tmp instead of /home/xx/tmp
Which also exists but don't have the right permissions
To clarify this are examples of the whole path:
/home/my-account/public_html
/home/my-account/tmp
/tmp
The workaround I used was:
session_save_path('/home/my-account/tmp');
session_start();
Using PHP 5.6 I had already used session_save_path() to point to a directory within the domain's structure. It worked fine until I upgraded to PHP 7.0, at which time I received the noted error. At PHP.net I found several comments that indicated assigning a direct path didn't always work, so I used their suggestion.
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));
worked perfectly. Remember to change /../session to the relative location of your actual session directory.
If :
session.gc_probability > 0
session files are created by different user(s) (e.g. root and apache).
session files are all stored in the same place (e.g. /var/lib/php/session)
Then you'll see this error when e.g. the Apache PHP process attempts to run garbage collection on the session files.
Fixes :
Reconfigure PHP so gc_probability is 0, and have a cron job removing the old/stale file(s).
Have each different user save their session files in separate place(s) (session_save_path() etc).
I initially had this issue due to nginx owning the /tmp location and php-fpm was running under 'apache' user and group due to the www.conf. I swapped out the user/group in that file and then it worked ok. You may want to check <?php echo exec('whoami'); ?> to verify.
In my case the problem was SELINUX not allowing this.
A helpful command to get suggestions on how to fix this:
sealert -a /var/log/audit/audit.log
If you want to rule out SELINUX, try disabling it for a moment. If that fixes the issue then that is the problem.