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.
Related
In my app i created folder “.app/” where users keep their uploaded files. I made such a name (with dot) to prevent meteor watch this folder. Because otherwise when user creates new folder server reboots.
But when I’ve deployed my app It crashes when user tries to create folder.
“Access to .app folder - denied”.
How can I solve this problem?
Usually the docker file system is read-only for the meteor process, which is why it fails. If you really want local file acces (not a great idea anyway, think about using Filestack or an AWS S3 bucket instead), well you will need to add a volume which is writeable, and will survive a docker image being blown away (which you occasionally will need to do).
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 am trying to install CiviCRM in my openshift wordpress 'gear' And I am getting the following when I attempt to run civicrm's installation wizard:
The user account used by your web-server - 542ddc2950044666c40008d9 -
needs to be granted write access to the following directory in order
to configure the CiviCRM settings file:
//var/lib/openshift/542ddc2950044666c40008d9/app-root/data/plugins/files
Does anyone know if what it is asking is possible?
and then how do I go about setting that?
Thanks!
The plugins/files/civicrm directory is where CiviCRM stores its cached templates, file attachments, premium (thank-you gift) images, and more. It'll need to save stuff there regularly, not just at first.
The best thing to do is to log in through SSH like developercorey recommends and:
cd ~/app-root/plugins
chmod 755 files (changing the permissions so the owner can write and everyone can read/execute)
chown 542ddc2950044666c40008d9:542ddc2950044666c40008d9 files (making the user that the web server runs as ("542ddc2950044666c40008d9" as mentioned in the error message) be the owner of the directory
have the installer check again
SSH into your gear using the rhc ssh command
cd ~/app-root/plugins
ls -lah
Look for the "files" directory and see what the user and the permissions are on that folder, you can change with the "chmod" command to allow it to be written to by the web server, but be careful what you do or you could cause a major headache for yourself (like getting your WP blog hacked). Hopefully the instructions for that plugin include setting the permissions to something reasonable when you are done.
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.
I am trying to install (copy) Wordpress files in my Webbynode. I can copy the files. But when I try to upgrade automatically I get a lot of permission errors. I only can solve them using chmod 777 in folders and files, what is not secure.
I'd like to know if someone can explain in simple words who needs to be the owners of the files and folders and/or what is the best way to install wordpress in Webbynode in order to not get these errors.
Thank you.
If you have control over your server, which I understand you have with that provider, you can set the owners of the folders to the same user as the one with which Apache is running, so the permissions could be 755 and the rest of the world won't be able to write into them.
To find out which user Apache is running as you can use:
ps aux | grep apache
Sometimes the process is named "apache2", or also "httpd", instead of "apache".