imagemagick can't overwrite files on Ubuntu 16.04

March 27, 2017 1.9k views
Apache LAMP Stack PHP Ubuntu 16.04
conorocean
By:
conorocean

I'm overlooking something to do with permissions for imagemagick. I set up a new Ubuntu 16.04 droplet exactly as per the DO guide, giving my new user root privileges etc. Ditto for the LAMP stack, exactly per the DO guide and everything ran well.

I install imagemagick. It works fine, I can do various commands with it, it's resizing and saving images I upload, until...

It won't overwrite any of the existing images it had previously saved. It throws:

object(ImagickException)#2 (7) { ["message":protected]=> string(105) "unable to open image `/var/www/public_html/images/abcd.jpg': Permission denied @ error/blob.c/OpenBlob/2712"

This is running fine on with the same code on my local LAMP development server, so I'm pretty sure it's a permissions issue (as well as it stating so in the error). What I don't understand is that I can write to the folder ok, just not overwrite? All images, their folders and parents have 755 permissions. I'm a bit lost.

I have nothing else unusual going on in terms of users. PHP executing a userinfo request on the page states the user is www-data.

Log In to Comment
1 Answer
ryanpq MOD March 27, 2017
Accepted Answer

In order for imagemagick when running as part of a PHP script to write files you would need to give permissions to the www-data user and/or group. If you uploaded these files with your user account or as root you would need to set these permissions manually. For example, if your web root is the default of /var/www/html then you could run:

chown -Rf www-data:www-data /var/www/
Reply
  • conorocean March 27, 2017

    I've already managed to write files using imagemagick, so I hesitated in changing permissions incase I was needlessly making the server less secure out of naivety. This also had me confused as it suggested I had permissions to write to the directory.

    I believe you're saying that if the image files that are to be overwritten were uploaded by a user account other than www-var (some were, through sftp), then this may have caused the issue. Gotcha. Thanks for the quick solution.

  • conorocean March 27, 2017

    Just to add...

    I should have thought of this in advance but I've now no write access from my main user account after running that command. It makes sense as I've just given permissions to the www-data user and lost permissions from my own.

    I'm presuming I should either join or create a group that both www-data and my default user are a part of and give ownership to that group instead. Any pointers? I'm going to research it in a moment.

    • ryanpq MOD March 27, 2017

      That is expected for the reasons you mentioned. The quickest fix for this is to add your SFTP user to the www-data group with:

      usermod -a -G www-data [your_username]
      • conorocean March 27, 2017

        Makes sense. I'm seeing that the flags 775 are discouraged and a secure server is recommended to have 755. I've added my default user to the www-data group fine but, due to the 755 flags, don't have write permission when connected by sftp. I could change permissions to 775 and have write permission for both the default user and www-var, but this is supposedly insecure. Is there a best practice?

Have another answer? Share your knowledge.

Related Questions