I don't understand why mPDF creates temp files using 600 as permissions.
I have a problem with Laravel because sometimes we create PDF using jobs, and sometime from webpage
If job run first, files are created as user:user with 600 as permission. So when www-data runs cannot read the files and it explodes. We added sticky bit to tmp folder so new file are created as user:www-data, but this is not enough, because of 600 as permissions.
Otherwise if web run first, files are created as www-data:www-data with 600 as permission. When a job run, it cannot read the files, because it's running as user. And it explodes.
At every deploy, we must manually run a creation of a PDF, change ownership to user:www-data and permissions to 664.
Is there a way to ask mPDF to create files as 664 instead of 600 !?
So at every update we do a manual run, and manually change
This issue has been resolved in the code.
From >= 8.0.11, files are being created with 664 permission.
Related
Every time I upload my theme folder(WordPress) from my Mac OS to my hosting server(CPanel), I have lots of permission errors and I should fix the permissions again on our server.
Is there any way to fix permission on my Mac OS to be compatible with my server permissions (folders:775 & files:644 )?
A quick google search found this at macinstruct.
How to Modify Permissions with chmod
For total control over permissions, you can use two Unix commands - ls and chmod - to display permissions and modify them. Assume you want to find a folder’s current permissions and then change them to 755. This would give you as the owner read, write and execute permissions, and everyone else read and execute permissions.
Here’s how to find a folder’s current permissions and change them:
Open the Terminal application.
Once you direct yourself to where your files/folders are located...
Type ls –l, and then press Return. The symbolic permissions of the files and folders in your home directory are displayed, as shown below.
Type chmod 755 foldername, and then press Return. This changes the permissions of the folder to rwxr-xr-x.
When it comes to using the ls and chmod commands, practice makes perfect. Try modifying the permissions on a couple of sample files. If you need more help, use the man command to display the manual pages for these commands (e.g., man ls).
I've recently setup a Phing build step to deploy a Wordpress website to an external FTP server.
The actual transfer works fine, but I'm trying to figure out a way to set the permissions on the uploads directory to allow users to upload files.
I notice on the FtpDeploy task in Phing that you can specify dirmode, but that seems to set permissions for all directories that are being deployed.
Can anybody tell me if it's possible to set the directory permissions and upload in a single step (task) or would I have to either do 2 FtpDeploy tasks (one for the bulk of the Wordpress site and a second for the uploads directory alone with the required permissions) or perform an ssh chmod after the deploy task.
If I have to do it in 2 stages, are there any benefits of doing a separate deploy with permissions over the ssh method?
Thanks in advance for any suggestions,
Phil
You set the permissions correctly on your local system, and use the dirmode="inherit" attribute.
I recently upgraded my Drupal core from 6.15 to 6.26. In the update process, I was asked to make a backup of all my files, then delete the entire Drupal installation from my server, and rebuild it using the supplied files. I then copied all relevant back-up files back to the server from my local machine. The problem I'm having now is that I get a "The directory is not writable" notification whenever I do any sort of action as an admin. Initially, I was getting the error that "sites/default/files" was not writable, but I fixed that, and I changed the permissions on every file in the installation to 755. Why am I getting this error, and how can I fix it?
Although permissions may be set to 755, most likely the directory ownership is set to the wrong user.
Just wanted to add this possibility, which fixed this issue for me after trying many things:
If you're running SELinux (like Fedora), you may have a "security context" issue on /sites/default or /sites/default/files. So even if you open it up using chmod 777 (not a good idea), you STILL get the permission issue.
the fix is (first cd to sites directory):
restorecon -rv default/
I ran this locally as root.
I don't pretend to be an expert on security contexts by any stretch, but Fedora documentation is here.
Hope that helps others avoid my headache!
After finding the permissions problem, you'll probably want to go back and chmod 644 for all files, and 755 for directories (besides the upload folder) just to be safe.
Drupal sometimes create some directories so check if sites/default/files sub directories have the right permissions
You can do it using two possible options:
1. change the owner of files directory and all files inside it to apache user
2. Give 777 permissions recursively to files directory
I am deleting files (wordpress theme files )of my website to the server using cPanel, but still the files are reappearing. The files have a 000 permissions set.
It is strange that files have proper permissions ( i.e. 777) when they are on my local machine, but on uploading they are getting changed to 000. Do you think the site is infected by virus ? I run an Anti-Virus scan, and found none.
Any reason why this may be happening?
chmod 000 denies read, write, and execute permission to yourself, your group, and everyone else.
How are the files uploaded to the server? Your FTP program might me screwing up the files when they are uploaded.
If you have root access you should be able to remove using $ rm -rf filename
Edit
The Umask settings on your server are not right. Setting Umask to 777 will make permissions 000.
If you have shell access you can check for 777 Umask values by running: grep 'umask 777' /etc/skel/.bashrc
If you find anything change the Umask to 022. If you don't have shell access your host should be able to fix this for you.
Instead of using the cpanel uploader use a an FTP program like Transmit for Mac or Core FTP Pro for windows and make sure to always use SFTP which is encrypted instead of FTP.
If you have the option, use FTP to manage your server files. It's more reliable than any web-based client.
If not, try changing permissions through cPanel to 777 before deleting them. If you are unable to do that, then contact the server administrator to resolve the issue (since it looks like a server/cpanel misconfiguraiton).
This is caused by the server recreating folders because you have subdomains or email addresses still attached to the domains related to those folders. Delete the subdomains and emails related to them and those folders will stay deleted.Happened to me before :)
Tim
backup other files in folder then delete folder.
create new folder with previous folder name (that was you deleted) and copy backuped files to it.
This may just work for other users who don't know how to do the techies, or who don't have shell access:
Check to see whether what you want to delete is a FOLDER or a FILE
If it is a FOLDER, check the permissions on that FOLDER and change to 755, do the same if it a FILE and simply delete
The issue here is that you have to open the FOLDER and CHANGE ALL SUBFOLDERS and FILES inside it to permission settings 755.
Delete the files from the inside of the SUBFOLDERS out then to the FOLDERS
This should perhaps help someone.
This has to do with media uploading in Wordpress.
Every time WP creates a folder for new uploads (it organizes uploads by year and month: yyyy/mm), it creates it with the "apache:apache' user and group, with full access to all (777 or drwxrwxrwx).
However, after that, WP cannot create a folder within that folder (e.g.: mkdir 2011 succeeds, but mkdir 2011/01 fails). Also, uploads cannot be moved into these newly created folders even though the permissions are 777 (rwxrwxrwx).
Once a month, I have to chown the newly created folders to be the same as user:group as the rest of the files. Once I do that, uploading works fine (which doesn't make sense to me The really frustrating part is that this problem doesn't exist in other WP installs on other domains on the same server.
* I wasn't sure if this should be here or on serverfault.
Edit: The containing directory /.../httpdocs/blog/wp-content/uploads has the correct ownership
drwxrwxrwx 5 myuser psaserv 4096 Jun 3 18:38 uploads
This is a Plesk/CentOS environment hosted by Media Temple (dv).
I've written the following test script to simulate the problem
<pre><?php
$d = "d" . mt_rand(100, 500);
var_dump(
get_current_user(),
$d,
mkdir($d),
chmod($d, 0777),
mkdir("$d/$d"),
chmod("$d/$d", 0777),
fileowner($d),
getmyuid()
);
The script always creates the first directory mkdir($d) successfully. On domain A, where the WP problem is, it cannot create the nested directory mkdir("$d/$d"). However, on domain B, both directories are successfully created.
I am running each script at /var/www/vhosts/domainA/httpdocs/tmp/t.php and /var/www/vhosts/domainB/httpdocs/tmp/t.php respectively I checked the permissions on tmp, httpdocs, and domain[AB] and they are the same for each path. The only thing that differs is the user.
A solution is to use FastCgi. This makes PHP run as the user who owns the site. New files and folders will be the same user and group. This will solve your problem.
There is a performance penalty to FastCgi but you get some added security as it restricts php. If you are hosting multiple website with multiple users this could be a good idea.
Try going to your miscellaneous settings page (or media depending on your version) and make sure the upload directory is still wp-content/uploads.
If you need to. set the full url too.
Also, as a final solution, disable the option to organize them into folders so that way WordPress doesn't even need to create folders.
Check for a setuid or setgid bit on a directory above the 2010 directory. ls -l will have an s or S in the permissions for the directory. Make sure this directory has the correct ownership.
Try to create directory recursive with mkdir($d, true)
<pre><?php
$d = "d" . mt_rand(100, 500);
var_dump(
array(
get_current_user(),
$d,
mkdir($d,true),
chmod($d, 0777),
mkdir("$d/$d", true),
chmod("$d/$d", 0777),
fileowner($d),
getmyuid()
)
);
I had a similar issue with Joomla recently, and solved the problem by adding myuser into the apache group, and add apache into the psaserv group.
One of our websites on a Media Temple DV was having this problem. Turning PHP Safe Mode off solved it. The directories were still created as apache:apache, but the media files were allowed in there.
One thing that occurred to me - WP will tell you that it can nto copy file to /wp-content/upload even when all permissions are right.... if
upload_max_filesize
in php.ini is too small (say 2M and you try to upload 3.5MB file)!
Hope that helps all thsoe who have right permissions but still can not upload!
You shouldn't need 777 on your directories, 775 at most should be sufficient. Just make sure it's set on the uploads directory with 755 for all the other directories above.
Also, you could try to chown it to www-data, sometimes that helps when your ftp user that you are logged in as when changing the permissions once a month doesn't have sufficient access level and owning the directories by that user prevents the server from being able to write into them.
Lastly, as someone has pointed out above, you may need to up the upload size limit along with making sure other file upload related php.ini settings are correct:
http://php.net/manual/en/ini.core.php
http://kb.mediatemple.net/questions/137/How+can+I+edit+the+php.ini+file%3F#dv
One common cause, often overlooked, is the disk quota, ie have you run out of disk space.