I have a WordPress site on my webserver and have recently copied it to my localhost testing environment using XAMPP (bitnami) to work on it, and proceeded to re-upload the site back to the server without issue.
Now, everything is functioning fine except for uploading images. Whenever I attempt to upload them, it says it cannot write to the directory.
I have tried turning off date/time arrangement of images, I've tried manually creating the folder its trying to use and temporarily setting the permissions of it to 777 and it works. However, when I change them back to 755 it stops allowing uploads again.
Like I said this has only happened since copying my localhost wordpress back. I've read it may be due to the account WordPress is using to create/write files. Is there any way to find out what this account is? And how would I ensure it has the correct permissions? Could it somehow have inherited the Bitnami XAMPP WordPress account since I copied the files/DB over?
I have access to my sites cPanel if that helps.
don't change permissions change owner
sudo chown www-data:www-data /folderName
Related
I am trying to give someone FTP access to an NGINX /var/www/sitename folder on an Ubuntu server so they can upload development files. I have created a user 'developername' and assigned them to the 'www-data-' group. They are able to upload files, but the images (apparently only the images) are not displaying on the site. I need to SSH in and change all of the files to www-data:www-data in order for them to display correctly.
I'm trying to find a way for this user to upload files and either automatically change them to www-data:www-data or to allow NGINX to use the developername:www-data files. Do you have any ideas?
I've just been using git for a couple of years now and had tried my best to not use FTP at all anymore... This setup is a little infuriating.
Thanks for your time and any responses!
In case someone else runs into this, I first got uploaded files to automatically be in the correct group by doing this:
chmod g+s root_web_folder_name
This made all uploaded files already have the www-data group. Then I went and updated the local_umask setting in the vsftpd.conf file:
local_umask=0002
Now images are appearing when the developer uploads new files. Make sure to set permissions correctly there, I just have it lax because it's a quick test site.
I am trying to configure the temporary directory on my Drupal install. Previously, I have been on a cPanel shared account, and all I would simply do is add '../tmp' to the settings and it all worked fine. I have recently outgrown my shared account and upgraded to a VPS, with CentOS and VestaCP. Now, when I enter '../tmp' it says that the folder 'does not exist and could not be created.' I have checked, and that folder is indeed there via file manager and FTP, is 755 permissioned etc. No matter what I try, it just doesn't seem to want to acknowledge it is there.
My CentOS and VestaCP installs have had VERY little tweaking, so they are pretty much default installs at the moment. I was advised to try a path such as:
/home/admin/web/MYDOMAIN/tmp
Other attempts have been:
/tmp and /home/admin/web/*/tmp
But they all threw up the same error. If I type just 'tmp', it works fine, but is then obviously within the web root directory, which is not ideal. Help?
In the end, it turned out that the best way is to use the pre setup and designated tmp folder for the whole install, which is located at /home/admin/tmp. This also allowed for uberCart credit card processing as well, which wasn't available via a normal ../cc either. The folder also allows for directories, so you could separate between domains and requirements, i.e.
/home/admin/tmp/domain.com or /home/admin/tmp/cc/domain.com
A client informed me that any time he tries to update a plugin, he gets an error:
To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.
I don't have FTPd setup on the server, but this seems like a basic permissions issue, right? I've never had to use FTP credentials to update any other WordPress installations.
Well, I did some reading and started messing with permissions and long story short, out of frustration, I eventually made everything writeable by everybody:
sudo chmod -R 777 src
But I'm still getting the same error. So it has to be some type of configuration issue, right?
I ran a few find . -exec grep commands to determine if there is a hard-coded document root (like in Joomla), but I came up empty handed.
Do I really have to install FTPd to be able to update WordPress from the admin interface?
Is there a config file somewhere that specifies the document root location?
Is there some other configuration option that I'm missing here?
Or maybe it's something in the database? The site was originally on a shared host but was moved to a DigitalOcean VPS a month or so ago.
I was able to force WordPress to use the filesystem instead of FTP by setting the FS_METHOD constant in wp-config.php:
define('FS_METHOD', 'direct');
More details can be found in the WordPress codex.
Try running chown -R apache:apache on the directory. I recall running in to an issue with ownership even when permissions were OK. You may have more success posting this on ServerFault as well.
I'm running IIS 8 on a virtual machine (Windows Server 2012 Datacenter) in Azure. I have installed WordPress and its dependencies using the Web Platform Installer 4.6
I have trouble when WordPress needs to write files from its admin console. I've added the ftp details to the file C:\inetpub\wwwroot\blog\wp-config.php and that works fine. But whenever WordPress tries to write a file from its management web page, for example to create a child theme or to upload media I got an error (e.g. 'failed to upload due to an error' or 'Target child theme directory cannot be created. This is probably a permission error'.)
I can fix this using EvilDr's idea of adding permissions to the IUSR account. But I am nervous about this since it seems that IUSR and should only have access to precisely what it needs; it should never be given access to anything else.
Is giving IUSR read Modify, Read & execute, List folder contents, Read, and Write permissions for the WordPress directory C:\inetpub\wwwroot\blog and its subfolders the correct and safest way to get WordPress working on IIS 8?
Giving NETWORK SERVICE write permission to the folders that WordPress needs to write to should do the trick.
UPDATE: NETWORK SERVICE will also need Read & execute, List folder contents and Read permissions.
EDIT:
Thought I'd add the file/folders etc.. for completeness:
/wp-config.php
/wp-content/ (recursively)
After moving a site from local to remote server. I cannot get the magento conect manager to install extensions. No obvious info regarding this paticular error online.
If give an extension url....it will show the preloader for a few seconds, before returning to the connect page, with no error.
If use the package uploader, initially i had a 'could not move files' error...but changing certain dirs to 777 fixed this. I did set all folders to 777, to test if this helped. It didnt.
Anyone know this error? Otherwise manual extension installs for me :(
Could this be apache related....or moving files via FTP from local to remote server? I say this based on some forum posts i read.
Thanks
S
If the following files exist try removing (or renaming if you prefer to be safer) them.
downloader/connect.cfg
downloader/cache.cfg
These are generated by Magento the first time you use connect. The cache file stores a full path to your install, so when you move to a new server this likely isn't a valid path.
chmod 777 var/package/tmp/package.xml
should do the trick.
the directory is from your magento home directory.
Maybe you run out of disc space. I raised disk quota on my server for this account, and the problem disappeared.
If you have SSH/CLI access and are using Magento 1.5+, try running ./mage mage-setup .
If you're on Magento 1.3.x or 1.4.x delete the files in /downloader/pearlib/cache/ and try again.
If you have cpanel hosting where the apache is configured to work with users such as nobody, apache etc.. then the problem is that. the owner of /home/user/public_html/var/package/tmp/package.xml will your cpanel user but this requires apache users permission. so the choice is to temporarily change the file permission to 777