I get this problem now and then, where I use an FTP account given to me by the host and use them in Wordpress FTP. But for some reason when updating themes for example, the new theme gets created under apache/apache and not user/psacln user name/group. So at that point I can't delete or do anything with those files as I am under psacln group.
I would like to find out more about why this may happen to avoid this problem - any suggestions are welcome!
Thanks in advance.
When you upload files via the wordpess admin page (like themes) the httpd process running as the apache user is actually creating them on your system--hence why they are owned by the apache user. I suggest this options to work around this:
Add yourself and apache to a new group called 'wordpress'
Use to change group ownership of your wordpress to the new group
Use set the sgid permission bit and the group write permission to all directories in the wordpress docroot.
The setting of the sgid bit will make all files added to a directory be the same group owner.
Assuming you've added yourself and apache to the same group, here's the linux commands to setup the directories to ensure files get created writable to all in the wordpress group:
chown -R :wordpress /path/to/wordpress/docroot/
chmod -R g+w /path/to/wordpress/docroot/
find /path/to/wordpress/docroot/ -type d -print | while read i; do SAVEIFS=$IFS; IFS=$(echo -en "\n\b");chmod g+s $i; IFS=$SAVEIFS; done
Additional thing that may be needed:
If you see apache creating files with group permissions without write, you may need to change the default umask for the apache user for creation of new files. By default it should be owner and group write allowed, but I know some accounts (like root user) have the default umask set to be group read only.
because apache's worker children run under apache's userid, and a "common user" on a unix system cannot make files be owned by some OTHER user. Only the root account can "give away" ownership.
Why? It'd be trivial for a normal user to make a file owned by root, or owned by another user. If a given system was running with user quotas, this would allow a user to completely subvert the quotas, or deny someone else access by "giving" them a bunch of huge files and exceeding that user's quota.
If you need access to those files, regardless of the unix ownership, you could look into using POSIX acls, which exist above/beyond the unix permissions.
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).
Noticed this when creating a new directory in unix, and was just curious as to why this is so.
Thanks
A new directory created by a user and owned by the user with full permissions is no big deal. However, a new file/program if executed accidentally or before configuration could have catastrophic results. So the designers decided to give you a layer of protection.
It also prevents other users from executing the file unless you specifically grant permission.
Because you need the executable permissions to naviguate into the directory.
So basic permissions allow user to read file (read file permission), and to access file in directory (directory execute permission).
Note that read permission on a folder allow user to list files in it. (But doesnt allow to read them unless execute permission is granted too as I said in the first place)
Basically, +x on a directory means that the user can 'execute it' hence change into it (replace user by group or other depending on position in permissions).
Hence drwxr--r-- means only user can change into directory. More here.
The directory needs to have executable permissions so you can do things such as cd into it. Also the executable permission lets you look into the directory for inode information of the files it contains.
More info can be found at this source.
When trying to automatically update Wordpress on www.legalbeagles.info from 3.9.1 > 4.0 I receive the following error:
An automated WordPress update has failed to complete - please attempt the update again now.
Not entirely confident in updating the files one by one manually, does anyone have suggestions of why this error may be appearing (novice so be gentle)?
And yes, I have read several others' questions but cannot see any similar issue answered in a way I may understand.
You need to check your file/folder permissions. Your webhost may have them set too strictly for WordPress to write its own temp folders and extract its own archive in /wp-content/upgrade/. See Changing File Permissions « WordPress Codex:
Typically, all files should be owned by your user (ftp) account on
your web server, and should be writable by that account. On shared
hosts, files should never be owned by the webserver process itself
(sometimes this is www, or apache, or nobody user).
Any file that needs write access from WordPress should be owned or
group-owned by the user account used by the WordPress (which may be
different than the server account). For example, you may have a user
account that lets you FTP files back and forth to your server, but
your server itself may run using a separate user, in a separate
usergroup, such as dhapache or nobody. If WordPress is running as the
FTP account, that account needs to have write access, i.e., be the
owner of the files, or belong to a group that has write access. In the
latter case, that would mean permissions are set more permissively
than default (for example, 775 rather than 755 for folders, and 664
instead of 644).
Or, try a manual upgrade; all that involves is uploading a few folders and core files (and not overwriting wp-content and wp-config.php). See http://codex.wordpress.org/Updating_WordPress#Manual_Update
I recently removed my ACL because my professor needed to copy certain files. Now I know I should have just granted his user permissions instead of removing it all using 'setfacl -b .' on my home directory.
So the question is how do I recover or set a new ACL to my home directory using setfacl/getfacl?
You can't 'recover' what you discarded in the way of ACLs. If you know what you had set previously, you can reinstate those remembered ACLs anew, carefully.
Basic Permissions
On a Unix system, the most important criteria for you are the group and other ones - they are not directly affected by ACLs, but they control the access not governed by ACLs, and you must get them right too. You need to decide what is appropriate in your environment. For many corporate settings, allowing group and others read access on files, execute on programs, and read and search (execute) on directories is appropriate:
chmod 644 file
chmod 755 program
chmod 755 directory
If you are not supposed to let other people borrow your course work, you would nail things down so that group and others are not allowed in at all:
chmod 600 file
chmod 700 program
chmod 700 directory
Or you can mix and match; allow flexibility and open access to your home directory, but restrict people underneath that. In some circumstances, you might allow group or other only execute permission on a directory (and only read on a file). Then other people cannot access the file unless they know its name, and they can only read the file, not modify it or the directory that holds it.
Don't forget to use an appropriate umask setting so files are created with the correct permissions by default. For many people, a umask of 022 is appropriate; neither group members nor others can write to the file or directory, but they can read files or execute programs.
Using ACLs
None of this requires ACLs. If you want to provide controlled access to certain groups or users and not to others, then you need to ensure you have the appropriate base-level permissions set, and you can then effectively add permissions for selected users or groups on the files or directories you choose.
The Solaris 10 man page for setfacl says that the command syntax is:
setfacl [-r] -s acl_entries file
setfacl [-r] -md acl_entries file
setfacl [-r] -f acl_file file
This does not mention the '-b' option mentioned in the question, so you may be using a different platform. Note that the ACL controls was going to be POSIX 1e, but was never actually standardized, so different platforms implement slightly different variants on the commands.
The Solaris 10 man page then goes on to explain how to set the 'acl_entries' part of the description, with a note that the default part can only be applied to a directory, but the default values will be used for files in the directory.
ACL Entry Description
u[ser]::perms File owner permissions.
g[roup]::perms File group owner permissions.
o[ther]:perms Permissions for users other than
the file owner or members of file
group owner.
m[ask]:perms The ACL mask. The mask entry indi-
cates the maximum permissions
allowed for users (other than the
owner) and for groups. The mask is
a quick way to change permissions
on all the users and groups.
u[ser]:uid:perms Permissions for a specific user.
For uid, you can specify either a
user name or a numeric UID.
g[roup]:gid:perms Permissions for a specific group.
For gid, you can specify either a
group name or a numeric GID.
d[efault]:u[ser]::perms Default file owner permissions.
d[efault]:g[roup]::perms Default file group owner permis-
sions.
d[efault]:o[ther]:perms Default permissions for users other
than the file owner or members of
the file group owner.
d[efault]:m[ask]:perms Default ACL mask.
d[efault]:u[ser]:uid:perms Default permissions for a specific
user. For uid, you can specify
either a user name or a numeric
UID.
d[efault]:g[roup]:gid:perms Default permissions for a specific
group. For gid, you can specify
either a group name or a numeric
GID.
You will need to decide who, apart from your professor, needs access to files. Maybe your lab partner does; maybe the teaching assistants do; maybe your whole year (but not the years below you - those above you probably already know what you know). But without any more information about your requirements for protection, no-one can help you more. And generally, it is easy to get the ACLs wrong - use sparingly, if at all, and use the standard Unix permissions as your main access control.
And next time, I suggest simply allowing your professor in by adding (not erasing) ACLs - or asking him where he wants you to copy the files to (putting the onus on him to sort out the permissions issues), or copying the files into a directory such as $HOME/tmp/prof.jones with 711 permission on the directory, 644 permissions on the files, and tell him which files are there for him to copy.
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.