Alright so I cannot for the life of me get rid of this error :
Warning!
ErrorException [ Warning ]: chmod(): Operation not permitted
COREPATH/classes/finder.php # line 511:
510: {
511: chmod($dir.$file, \Config::get('file.chmod.files', 0666));
512: }
Here is my setup for permissions :
(775) : drwxrwxr-x myuser:nginx
Groups :
nginx:x:499:myuser,nginx
PHP-FPM Config
user = nginx
group = nginx
So this works for creating / editing files ect. and that all works fine.
How can I get this to work correctly?
As root, try:
chown nginx:nginx /your/directory/to/fuel/ -R
Also don't forget to run inside the FuelPHP directory:
php oil r install
in order to make the necessary directories of FuelPHP writable
It was because nginx had created a file, it has to be the owner.
PHP runs as www-user (or similar) - check your permissions against that.
What is you full path to file you are chmod'ing ?
For example if its: /var/www/website/fuel/app/tmp/myfile.jpeg
try checking the permissions for:
ls -la /var/www/website/fuel/app/tmp/myfile.jpeg
ls -la /var/www/website/fuel/app/tmp
ls -la /var/www/website/fuel/app
ls -la /var/www/website/fuel
ls -la /var/www/website
ls -la /var/www
And compare them
If think some of parent directories are just not 'writeable by others'
Related
I'm trying to get a simple PHP file to work on a linux Centos 7 server using apache. The problem is that the php code doesn't seem to have permission to write to the folder. The simple test php file below illustrates the problem
<?php
echo shell_exec('whoami');
echo "<br>";
$myfile = fopen("test.txt","w") or die("could not open test file");
fclose($myfile);
?>;
Just to try to get it to work I have done
sudo chmod -R a+rwx /var/www
and yet I keep getting the "could not open test file" error message. What am I doing wrong? Incidentally, the 'whoami' is coming back as 'apache'
**Edit*
In the light of the suggestion below I've done some changes and am now showing the full permissioning for the folders. I've created the group www-data and have added the user apache to it.
[prompt]$ groups apache
apache : apache www-data
For /var/www:
0 drwxrwsrwx. 4 root www-data 33 Jul 27 08:19 www
For /var/www/html:
0 drwxrwsrwx. 2 root www-data 137 Jul 27 12:43 html
The file I'm trying to load:
4 -rwxrwxrwx. 1 root www-data 182 Jul 27 12:40 test.php
It's still not working unfortunately. Might it be something in the apache configuration? Any suggestions would be much appreciated
Here are two options you can try
Option 1
Make sure the group is www-data on '/var/www'.
prompt> sudo chgrp www-data /var/www
Make '/var/www' writable for the group.
prompt> sudo chmod 775 /var/www
Set the GID for www-data for all sub-folders.
prompt> sudo chmod g+s /var/www
Your directory should look like this on an 'ls -l' output.
drwxrwsr-x
Last, add your user name to the www-data group (secondary group).
prompt> sudo useradd -aG www-data [USERNAME]
Option 2
Use the mod_userdir as described in https://httpd.apache.org/docs/2.4/mod/mod_userdir.html
I would recommend the first option as it suits your needs better.
I found my crontab scripts do not work as expected because they cannot write on /var/log. I tried executing command:
sudo /usr/bin/php /var/www/html/iPhone/inarrivo/php/rome/process.php >>
/var/log/romeLoading.log 2>&1
by hand and got:
-bash: /var/log/romeLoading.log: Permission Denied
/var/log permissions are:
drwxr-xr-x. 13 root root 4096 15 ago 16.20 .
If I conversely execute:
sudo touch /var/log/loadRome.log
I get no error whatsoever.
What could be the issue?
Please note Apache is not at stake: I am calling those scripts from the root crontab and from the shell with sudo as a test.
best guess: the user running the shell doesn't have write access to /var/log/romeLoading.log , and the stdout redirect (>>) is redirected by the shell user, not the sudo user, thus the access denied on >> , but not on sudo touch. maybe try
sudo sh -c '/usr/bin/php /var/www/html/iPhone/inarrivo/php/rome/process.php >> /var/log/romeLoading.log 2>&1'
that should run sh as root, and have the root-sh do the redirect with root permissions. untested though.
and next time you want to post permissions for debugging, post the namei -l path/to/file output, it gives much more info than stating the single file itself when debugging permission issues, as the issue can be higher up than the file itself, like the folder its in, or the folder that the folder it's in, is in, etc~ and namei gives you, recursively, detailed permission information on all of them.
It's a permissions issue as the log file belongs to root user and apache runs off www-data. Try chown www-data:www-data /var/log/loadRome.log.
I'm using CodeIgniter's upload helper and received the above error when trying to upload an image. The permissions for the folder I'm trying to upload to are 755. When I changed it to 777, the error went away, but isn't 777 kind of a security risk?
I'm running on Apache. Is there a better way to allow users to upload files without setting the folder permissions to 777? How can I get 755 to work?
Thanks for the help!
If the folder is for loading files by users than permisision 777 is required.
It's up to you to validate what files are loaded through upload script.
Also you can use .htaccess to alow or not alow certain files to be executed from that directory.
The documentation for upload in codeigniter it's pretty simple and intuitive. Also here you can look at some ways to validate the type of files that are uploaded https://codeigniter.com/userguide3/libraries/file_uploading.html
I don't think so giving any folder on server 777 permission is good. Instead giving 777 permission i suggest make www-data user as owner of desired folder and give 755 permission like below
chown -R www-data:www-data /var/www/html/uploads/
For 755 permission
chmod 755 -R /var/www/html/uploads/
In my NGINX + PHP-FPM installation the issue was solved changing the SElinux parameters from enforcing to permissive:
edit and change options with vi /etc/selinux/config
apply options without restart with sudo setenforce 0
check the status with sestatus.
try this:
sudo chmod 777 -R /path/to/write/folder
I know this is not an active question and may not be an issue for most but because I came across this I wanted to clarify for anyone else that may see this.
You DO NOT need 777 permission on your upload directory. This is actually not a good idea. The last 7 means it is public writable which does not need to be in most cases. Typically 755 should be good enough
More than likely the issue is that the directory is not owned but the user running Apache which is typically www-data
Step by step:
Check owner of dir (i.e.)
ls -l /path/to/upload/
Output should show similar
drwxr-xr-x 4 www-data www-data 4096 Oct 26 20:41 uploads
If not then you should change to www-data if that is the user Apache is running under. To check what user apache is running under :
ps aux | egrep '(apache|httpd)'
This should list something similar:
www-data 419 0.0 0.9 556292 156656 ? S 18:46 0:00 /usr/sbin/apache2 -k start
Hope This Helps!
I have a function in PHP language to create an xml file when requested.
if(($file= fopen("./include/catalogo.xml", "w"))==false){echo 'non creo il file'; return false;}
"catalogo.xml" can't be created, permission denied. I know I should try to change permissions, but how can do this if the file doesn't exist? Or, are there things that I ignored?
I think you might be ignoring the permissions of the directory (./include).
I'm assuming you are running this PHP via a web-server and on Linux (like Apache for example) - in which case the user account that is trying to create the file will be 'apache' or 'www-data' (or whatever user your webserver is running under).
On your server - have a look at the permissions of ./include - you need to do one of two things:
a) make ./include world writable (so the 'apache' user can now create a file inside of it).
b) change the owner or group of the ./include to 'apache' so it can create a file inside of it.
Your PHP is fine - it's the permissions of the folder it is trying to create the file inside of that is not.
You have to change the ownership of the directory "include" and set it to the web server's user and set the permission to a reasonable value:
$ sudo chow www-data include
$ sudo chmod 755 include
If you don't know which user your web-server is running by you can open the include dir permissions world-wide:
$ sudo chmod 1777 include
after create the creation of catalogo.xml you check the include diretory:
$ sudo ls -al include
-rwxr-xr-x 1 http web 4096 May 5 15:37 catalogo-xml
Now you can change the ownership of the directory "include" and set it to the web server's user (http) and reset the permission to a reasonable value:
$ sudo chow http include
$ sudo chmod 755 include
See also the manual of chmod, chown and ls:
$ man chmod
$ man chown
$ man ls
If you use the terminal and go to the parent of folder your file will be created in, which is the parent of the include folder and type in the command:
chmod 777 include
This should change the permissions of this folder so you won't receive the permission denied error anymore. If you do try this command:
chmod -R 777 include
Just a Question Regarding unix and PHP today.
What I am doing on my PHP is using the Unix system to untar a tarred file.
exec("tar -xzf foo.tar.gz");
Generally everything works fine until I run into this particular foo.tar.gz, which has a file system as follows:
Applications/
Library/
Systems/
After running the tar command, it seems that the file permissions get changed to 644 (instead of 755).
This causes Permission denied (errno 13) and therefore disabling most of my code. (I'm guessing from lack of privileges)
Any way I can stop this tar command completely ruining my permissions?
Thanks.
Oh and this seems to only happen when I have a foo.tar.gz file that Has this particular file system. Anything else and I'm good.
If you want to keep the permissions on files then you have to add the -p (or --preserve-permissions or --same-permissions) switch when extracting the tarball. From the tar man pages :
--preserve-permissions
--same-permissions
-p
When `tar' is extracting an archive, it normally subtracts the
users' umask from the permissions specified in the archive and
uses that number as the permissions to create the destination
file. Specifying this option instructs `tar' that it should use
the permissions directly from the archive.
So PHP code should be :
exec("tar -xzfp foo.tar.gz");
Edit: --delay-directory-restore solved the problem below about being unable to untar a file. The permissions of pwd are still altered, so the problem of the original poster might not be solved.
Not really an answer, but a way to reproduce the error.
First create some files and directories. Remove write access to the directories:
mkdir hello
mkdir hello/world
echo "bar" > hello/world/foo.txt
chmod -w hello/world
chmod -w hello
Next, create the tar file from within the directory, preserving permissions.
cd hello
tar -cpf ../hw.tar --no-recursion ./ world world/foo.txt
cd ..
Listing the archive:
tar -tvf hw.tar
# dr-xr-xr-x ./
# dr-xr-xr-x world/
# -rw-r--r-- world/foo.txt
So far, I've been unable to untar the archive as a normal user due to the "Permission denied"-error. The archive can't be untarred naively. The permissions of the local directory change as well.
mkdir untar
cd untar
ls -ld .
# drwxr-xr-x ./
tar -xvf ../hw.tar
# ./
# world/
# tar: world: Cannot mkdir: Permission denied
# world/foo.txt
# tar: world/foo.txt: Cannot open: No such file or directory
# tar: Exiting with failure status due to previous errors
ls -ld .
# dr-xr-xr-x ./
Experimenting with umask and/or -p did not help. However, adding --delay-directory-restore does help untarring:
tar -xv --delay-directory-restore -f ../hw.tar
# ./
# world/
# world/foo.txt
ls -ld .
# dr-xr-xr-x ./
chmod +w .
It is also possible to untar the file as root. What suprised me most is that tar apparently can change the permissions of pwd, which is still unsolved.
By the way, I originally got into this problem by creating a tarball for / with
tar -cvpzf backup.tar.gz --exclude=/backup.tar.gz --one-file-system /
as root (pwd=/) and untarring it as a normal user to create a linux container.