CAN Install New Plugins but CANNOT Upgrade Them

Do NOT change permissions to 777! That makes your system extremely vulnerable to attacks.

It sounds like it is a permissions issue, the scripts don’t have write permission to the plugin ditectory.

It would help to know more about your configuration. You say you are running the server on your local machine? What setup are you using, & what OS?

Oh, I know the dangers of changing permissions to 777. I use these basic Unix commands all the time at work. I know that if I open up read/write permissions to the world and it STILL doesn’t fix my issue, it’s more than just permissions. You can get a quick glimpse as to whether or not it’s as simple as not having write access by opening it up to 777– just to pull out all the stops and be absolutely sure. In my case, it’s not that simple. Unfortunately.

I just looked at it again via SSH just to make sure I’m not an idiot, and sure enough, upgrade and plugins directories currently have rwx permissions for user, group, and everyone, and plugin upgrades still fail. The directories are owned by the same user that WordPress is using to SFTP in and copy these files around.

It’s running on a funny Linux customization– perhaps you’re familiar with Synology Disk Stations? DSM 4.3. I didn’t use Synology’s WordPress package– I manually installed WordPress. Synology has set up their own custom configuration on just about everything– PHP, MySQL, and Apache– and they don’t necessarily keep them all up to date with each DSM release. It’s extremely difficult to try to install your own version of PHP, MySQL, or Apache, not to mention warrantee-voiding, supposing you brick your machine and want them to fix it. I can give exact versions if necessary, but they’re not ancient by any means.

Done!

I’ve been developing a hunch, and as odd as it sounds to my brain, it happens to be the correct hunch.

The Synology DSM uses a user “nobody” and group “nobody” to own its core files and run Apache. Now, in my basic Unix thinking, setting read write permissions on every possible directory would theoretically open it all up for anyone to write to– including hidden system users. Not so. Turns out it really did have to do with permissions, but probably a lot weirder types of permissions than most people have to deal with. Weirder than I’ve ever had to deal with on any other Unix-like operating system– WordPress or otherwise.

After setting the owner of the entire WordPress directory to nobody, I’ve been able to update my plugins and core files at last.

For the layman who may show up looking for tips on how to get his Synology WordPress installation working, you’ll need to know how to access a command line interface on your machine– usually this is done from another computer, especially when it comes to Synology DiskStations. Look up the basics if you don’t know what this is.

First you’ll need to enable SSH on your DiskStation if it’s not enabled already. Log in to the DSM, go to the control panel, click on “Terminal”, and click the checkmark enabling SSH.

From another machine’s command line (often called Terminal– if you’re using Windows, you’ll either have to get PuTTY or use Telnet and cmd.exe, but I’m not outlining those here), type ssh root@server-ip-address-or-dns-name-here.

Enter your password for your regular admin account. You’re logging in as root here, but the password will be the same as your admin user.

Type chown -R nobody:nobody /volume1/web

Or, if you have virtual hosts (multiple websites) set up on your machine, type chown -R nobody:nobody /volume1/web/yoursitedirectory

‘/volume1/’ may be ‘/volume2/’ or some other number depending on how you set your machine up.

Try some upgrades. They ought to work just dandy!

I’m working a lot with a few DiskStations and have to learn a lot of quirky things about them, so if anyone comes across this needing additional help, feel free to contact me.

Hello Weildish

I have been searching the internet for years for this particular problem. Unfortunately the fix with “chown -R nobody:nobody /volume1/web/yoursitedirectory” didn’t workout for me. I have a Synology DS1511+ and all the admin rights, enabled SSH, and I have tried the 777 option also.

I tried to reboot the system after the new permissions were set.

I tried your fix while running DSM 5.x, which is the new version.

I would be enormously thankful for a solution.

I have had success today with DSM 5 using:

chown -R http:http /volume1/web

Theme update doesn’t work though…? Everything else seems to work, and I can update plugins and plugins can update/change files and pesmissions, etc.

I just saw your posts– I’m sorry that I didn’t see them earlier or I would have responded.

With a new WordPress installation, I’ve noticed that the same issues you describe are happening. I’m not sure what changed, but I still have an older site owned by nobody:nobody that still can install its own plugins. However, like you described, chowning new virtual hosts to nobody:nobody doesn’t seem to work anymore.

I’ve resolved that. It appears that in one of the DSM 5.x updates the past few months Synology changed default ownership for the web host. Now you should be able to use something like this to get plugin/theme installations/upgrades to work:

chown -R http:http /volume1/web/virtualhost.com

That should be it!

Thanks all, still working like a charm. Updated after this in a couple of secs.
I imagine this could/should be easily solved in a new DSM version.

DSM 5.1 5021