Is there a better solution rather than changing wp-content folder persmission to 777 to prevent asking me to put ftp parameters? - wordpress

I have a running wordpress website and the only issue I have is that each time I want to save an update it's asking me to enter my ftp password.
Is there a better solution to remove this popup without changing wp-content folder permission to 777?

I have run into this issue when the files on my web server are configured with the wrong owner or group.
From the 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).
https://codex.wordpress.org/Changing_File_Permissions
This is something that you will need to resolve on your web server if you know your user and group. Your username is likely the same as your FTP user.
chown -R user:group /path/to/wordpress
If you are on a shared hosting environment you will need to contact your host so that they can fix this problem.
You should also avoid using 777 permissions on your folders. Folders should be 755.

Related

How to update Wordpress files through git remote pushes if user doesn't own the directories?

All Wordpress files and directories are owned by www-data user/group (Apache), directories are 755, files are 644. So, if I'm trying to git push something to the server using my ssh account, my user can't create any files, so I can't push anything.
The user is in www-data group, so changing Wordpress permissions to 775/664 looks like a solution, but it feels too permissive for the site's safety. I need a bit of advice.

your content folder is not writable wordpress

Can somebody help me please. I have getting a headache. I recently moved my server. The website run as normal but when I try to add content. My wordpress site shown. "your content folder is not writable"
I have did changing the permission to 777 to recursive folders but it won't work. I also tried to change it from ssh which code
chmod -R 777 /home/admin/public_html/wp-content/uploads
surprisingly, the admin dashboard still show the same error. I really appreciate any helps. Thank you.
That's a server permission problem. According to the WP docs:
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).
From http://codex.wordpress.org/Changing_File_Permissions
And, FYI, search first for a common issue like permissions; there are many answers already on WP permissions.

Filepermission in WordPress not working well

I've a problem with my WordPress. When I'll upload a media file and W3 Total Cache gives a error with the filepermissions.
When I login with SSH and change the group from example user:user to apache:apache
sudo chown -R apache:apache wp-content
Everything is fine. W3 Total Cache gives no error and the media upload will work fine. But when I'll change with FTP a file, there is a error that I have no permission to edit the file. When I'll change it back to user:user the errors return in WordPress W3 Total Cache and I can't upload with media
This is with all users on my server. Is there a way to change this, so I have permissions in WordPress en with a external FTP program like Filezilla?
You could change it to user:apache permission. Set user group and apache user. It allow Apache to work with this files and allow your FTP client work with same files too.
You could use chrooted ftp using sftp. It's pretty logical to have such issues since the user and group for your ftp user are different than the user/group for the user under which the web server runs

VPS FTP access to Wordpress

I've set up a VPS with LEMP on Ubuntu 16.04 and installed Wordpress with this tutorial
How can I setup a FTP account to access my Wordpress files?
Create a new user (for FTP access) with its home directory as the web root.
E.g
useradd -m -d /var/www/html USERNAME
That will create a user with the web root as its home directory.
Then you can sort the password out:
passwd USERNAME
And then use an FTP server like vsftpd and it will work when you log in.
You might have to mess with the permissions a bit. E.g adding the user to the web server group and giving the files and folders correct permissions.
https://www.ostechnix.com/install-vsftpd-server-ubuntu-16-04-lts/
For permissions see this
Correct file permissions for WordPress
You might need to tweak the groups etc depending on what you setup.

Wordpress upload image error

I've built a wordpress website on my mamp localhost, and subsequently uploaded it to a web hosting service.
Since I've uploaded it I cannot upload images via the wordpress 'add media' section. I temporarily change the 'uploads' permissions to 777 and it solved the problem.
I know 777 isn't best practise so I changed it back to 755 and the error has reoccurred.
Is this something to do with the admin user and password I originally set up for wordpress on my localhost versus the ftp user which I created and used to upload the site to the web hosting service?
Does the ftp user own the files - therefore stopping the wordpress admin user from uploading files?
Thanks
Files should be 644, directories should be 755. This is an owner:group permissions issue. Read more in Hardening WordPress.
The real issue is an ownership issue. You're going to need to chown -R username:groupname to your Apache user/group, so that WordPress can write to these directories.
chown -R username:groupname your apache user/group fixed the problem.

Resources