Joomla permission problem when installing/updating addons.

Discussion in 'Installation/Configuration' started by Nap, Feb 12, 2015.

  1. Nap

    Nap Member

    I've posted about this in the Joomla forum, but haven't got a resolution yet. Sorry for posting about this here, but I have a feeling my problem has something to do with how I've setup the server.

    I'm runing php using fast-cgi.
    My initial Joomla setup went through without problems, and I was even able to install a couple templates and an addon.
    When using the site (front and back ends) everything works fine.

    Now, when I attempt to install/update anything, I'm get permission problems with my folders/files.
    I've found that adding the Group WRITE flag fixes the problem. However this is not desirable according to Joomla's security recommendations. And it also means that I have to change permissions of existing addons before I update them.

    I've disabled the apache security2 mod (because it was detecting SQL Injections) which I have installed but the problem persists.

    Anyone know what is wrong?

  2. till

    till Super Moderator Staff Member ISPConfig Developer

    1) php mode has to be php-fcgi or php-fpm
    2) suexec has to be enabled in the website
    3) all files and folders inside the "web" folder of the website have to be owend by the web user and client group of this website.
  3. Nap

    Nap Member

    Yes, that's how I have things setup, I have "Fast-CGI" selected in the ISPConfig screen.

    I've created a fresh Joomla install on a new site, and its worked. I've compared the folder/file ownerships between the two sites and they are identical, yet it won't work on the original. I don't know why the original isn't working, perhaps it has something to do with the fact that I've added and removed a lot of addons whilst trying them out.

    I'm going to migrate the data to the fresh install and work with it instead.
  4. Nap

    Nap Member

    I don't understand why it's not working. And I'm determined to figure it out.

    In ISPConfig3, I have all the boxes ticked for this site.
    In documentroot (/var/www/clients/client1/web4/web) the folder permissions are 755, file permissions are 644, and owner permission are web4:client1 for all files; (except .htaccess etc.).
    In /etc/group I have client1:x:5005:www-data

    In a terminal, when switching to user www-data (su -s /bin/bash www-data)
    If I'm in the /var/www/clients/client1/web4/web folder, I cannot list the folder's contents. But I can cd into a subfolder. (Because I know what folders exist.)
    When I'm in a subfolder of documentroot, I can list files.

    I thought it might be like this because somewhere along the way I must have typed chattr +i web while in the web4 folder, but using -i doesn't change the behaviour.

    What would cause the permissions to behave like that? Is it something in the vhost file?

  5. till

    till Super Moderator Staff Member ISPConfig Developer

    You mix up users and permissions here.

    1) you have to enable suexec in the website settings.
    2) The website is running as the user of that site e.g. web1 for the first site, web2 for the second and so on. It is never running as www-data.
    3) all files inside the web folder have to be owned by the user of this website. Go to that site on the shell, find out the username of the user that runs the site (the user that owns the "web" folder and run a chown -R to the user of this website and to the client group of that site so that every file and folder inside the web directory are owned by this user and group.

    IMPORTANT: Do not alter any permissions or change the chattr!
  6. Nap

    Nap Member


    I've discovered the problem. The whole site was using the wrong user, but because the wrong user was in the same group as the right user, enabling the Group Write flag seemed to fix the problem.

    I originally setup this site as a backup of one I was working on at the time. I can't recall how I actually moved the files (tarred with permissions, or copy), but I overlooked the user problem. In fact, I streamlined the user to the wrong one.


Share This Page