Im not sure whats going on. This plugin worked great before. Now it's complaining about file permissions I have tried everything up to and including 777. Ive removed the -linux, and then finally just copied the old OptiPNG version 0.7.4 and old LCDF Gifsicle 1.68 into a new ewww folder.

except...the red content warning box will not go away.
EWWW Image Optimizer couldn't install optipng and gifsicle in /var/www/example.com/htdocs/wp-content/ewww/. Please adjust permissions or create the folder. If you have installed the tools elsewhere on your system, check the option to 'Use system paths'.
it seems something is wrong. what i have no idea. This is the third attempt to update this plugin resulting in failure. Seems everythin is working I just cannot figure out why it is complaing about the ewww folder permissions.

update: reset APC cache and the settings page wanted gifsicle updated. downloaded latest version of plugin unzipped renamed gifsicle removing -linux and uploaded. That seems to have worked everything is reading ok now but the content box warning is back to

EWWW Image Optimizer couldn't install tools in /var/www/example.com/htdocs/wp-content/ewww/. Please adjust permissions or create the folder. If you have installed the tools elsewhere on your system, check the option to 'Use system paths'. For more details, visit the Settings Page or the Installation Instructions.

I also went to reoptimize a few images which failed
content/uploads/2013/03/T4yADGa.jpg is not writable.

Im going to restore server backup again and wait for an update. Should my image files themselves be group writable? It wasnt necessary before. I am sure this is some stupid little thing I am not thinking of.

ps didnt mean to sound like a d-bag this is a great plugin and I have become reliant on it especially for one client. I just am a little frazzled as to why I cant get the darn thing working like it was before the update.

It sounds like the files in your wordpress install do not have the correct owner, if you are having trouble even with your uploads/ folder. Make sure everything in the htdocs folder is owned by the www-data user.

Something like this should do it:chown -R www-data:www-data /var/www/example.com/htdocs

http://codex.wordpress.org/Hardening_WordPress
"All files should be owned by your user account, and should be writable by you. Any file that needs write access from WordPress should be writable by the web server, if your hosting set up requires it, that may mean those files need to be group-owned by the user account used by the web server process."

thats from codec. user:www-data. 755 and 644, except for uploads(and wp-config.php). I self host so group ownership isn't necessary or appealing to me.

www-data group has read and write on wp-content/ewww folder.
I shouldnt be seeing that warning. Restoring last version of the plugin doesnt do it. I'll bump up the permissions on htdocs to make it writable to check but i dont want to keep my webroot owned by www-data.

Also I dont have issues uploading.
Thanks for the quick reply. If I am missing something I apologize for wasting your time. Ill check it out tomorrow and get back to you.

that setup should be fine, I just generally do it differently. Especially on a server I have full control of, I make all files owned by www-data, and then adjust permissions accordingly.

The reason (I think) that they go that route, is that php will refuse to modify any files not owned by the web user (www-data), so it is an easy method of security, but you can accomplish the same thing by just taking away write permissions.

Anyway, the important 2 things we are looking at is the 'ewww' folder, and the 'uploads' folder.

From my understanding, the uploads folder must be owned by www-data, in which case user-writable is fine. From the above, sounds like group-ownership will also work, but you would also need to make it group-writable as well, which sounds like that may be what you are running into with the images.

On the 'ewww' folder, there could be many things happening. The most common issue is that the binaries get corrupted by ftp uploading them. They MUST be transferred in BIN (binary) mode, or it just doesn't work. To keep your tight security, it should be sufficient to temporarily make the ewww folder 777, make sure it is owned by www-data, and visit the settings page to trigger the tool install. Once that is done, you can remove all write permissions from ewww until the next upgrade that includes new binaries. The primary thing that triggers the tool installer is a mismatch in size between the binaries in the plugin folder (ewww-image-optimizer), and their final destination (ewww). It also attempts to ensure that the tools have 755 permissions as well, so if they don't, it will complain if it can't fix that too.

Ironically, I just completed some debug code on that function in the latest 'dev' version of the plugin. If you install that, turn on Debugging, and then refresh the settings page, there will be a fairly detailed log at the bottom of the page (in yellow, can't miss it) that should tell us what is going on.

yeah, the binaries themselves need 755.
The ssh-sftp updater shouldn't be a problem. I always use sftp/ssh for transferring the binaries between machines, and haven't had an issue. As far as I know, they transfer files strictly in binary mode.

I changed ownership of wp-content/ewww/ and /plugins/ewww-image-optimizer
to www-data it all installed then I changed it back they way I had it before.

For me I have a multisite network with 10 or so blogs in it as well as 4 or 5 individual WordPress installs. With ownership as www-data I wouldnt be able to give clients sftp access to their sites without adding them to www-data which would in turn give them access to the other blogs.