We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
MODX Community Forums Archive

Answered core/components directory permissions breaking Package Management

    • 34163
    • 11 Posts
    Stretched Reply #1, 11 years, 5 months ago
    I've upgraded from 2.2.5-pl to 2.2.6-pl trad. I ran into problems with permissions and had to upload a backup of the site. The upgrade was successful, but the final message was:

    Important Note:

    Your core/components/ directory was not created at: /var/www/xyz.com/core/components/
    You will need to create this directory and make it writable if you want to use Package Management or 3rd Party Components.

    /core/components does in fact exist from the previous 2.2.5 installation and contains the packages I had installed: Wayfinder, getResources, FormIt and TinyMCE. The site is working, except that when I go into Package Management a similar message about /core/components appears at the top of the page. I can see all the previously installed packages, but I can't download new ones – the "Please Wait... Downloading..." dialog sits there in an endless loop.

    The permissions on the /core/components directory were 755 with my ftp user as the owner. Changing to 775 made no difference. 777 made the message disappear, but packages still won't download and I don't really want open doors like that on the site. I tried doing the same with /core/packages but the problem persists.

    What should the permissions be on these directories and who should be the owner? I've seen some directories elsewhere in MODX with an owner of www-data. Is there anything else I should look at that may be causing the problem?

    Thanks.

    PHP 5.3.6-13ubuntu3.9 256M
    MySQL 5.1.66-0
    Apache 2.2.20

    This question has been answered by markh. See the first response.

    • Frogabog Reply #2, 11 years, 5 months ago
      This is oddly similar to another issue with packages not installing or uninstalling after upgrade/reinstall/moves. Although you're getting error messages and that hasn't been reported yet.

      In the workspaces table, change {core_path} to an absolute path to the core/components directory. Does that fix it?
        Frogabog- MODX Websites in Portland Oregon
        "Do yourself a favor and get a copy of "MODX - The Official Guide" by Bob Ray. Read it.
        Having server issues? These guys have MODX Hosting perfected - SkyToaster
      • discuss.answer
        Mark Hamstra Reply #3, 11 years, 4 months ago
        You shouldn't change {core_path} to an absolute path in the workspaces table; you'll hate yourself when you end up migrating. The {core_path} will be replaced with the MODX_CORE_PATH constant that is defined in the config.core.php paths in the webroot, manager or connectors directory. So if the workspaces table gets the wrong path, you need to look elsewhere for a fix wink

        You can chown (change the owner) the directory (and its subdirectories) to the www-data user, and then you can set hte permissions back to 755.

        Or ask your host to install phpsuexec on the server, so you don't have to mess with file permissions and owners and all that stuff.
          Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

          Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
        • Frogabog Reply #4, 11 years, 4 months ago
          I don't think changing the {core_path} is a solution, but rather part of figuring out the problem.

          I've not changed it in my installs, because it works for all new packages as it should, and I've already uninstalled and reinstalled them all anyway. But if it fixes the problem for the OP, we can assume that the OP's issue is the same as the other few similar that have been reported and call it the same bug or... whatever it is.

          By all accounts {core_path} should work 100% of the time. But it doesn't seem to for existing packages, if you reinstall from DB or move. Bug or no?
            Frogabog- MODX Websites in Portland Oregon
            "Do yourself a favor and get a copy of "MODX - The Official Guide" by Bob Ray. Read it.
            Having server issues? These guys have MODX Hosting perfected - SkyToaster
            • 34163
            • 11 Posts
            Stretched Reply #5, 11 years, 4 months ago
            @Frogabog - for what it's worth I tried an absolute path, but the message still displayed and it wouldn't download new packages. Thanks for the suggestion.

            Mark, I'll give your suggestion (chown) a try. Will also check to see whether phpSuExec is already on the server.

            thanks.
              • 38169
              • 7 Posts
              cktdesign Reply #6, 11 years, 4 months ago
              MODX using php must be able to write to packages folder. I guess you are running on a server with php installed as apache module and not as cgi and that you dont have ssh access cause then you would have solved the problem allready.

              Since your package folder is owned by the ftp user (and php seems to run under apache in your server which is not in the same group as the ftp user) you will need to 777 that folder (and others i guess like cache etch).

              To be able to have all folders in your modx site 755 in a server configuration where apache runs as a module and there is no ssh access you will have to stop using ftp/cpanel/da to transfer files (because they are created under the ftp user) and only use php file browsers (which creates files under the apache user). I personally use the modx browser and ajaxplorer in the servers with apache module but i am sure there will be many more php scripts you can choose (ajaxplorer is amazing because it has a java plugin which allows you to upload a folder with 20000 files with a simple drag n drop but i dont think it is secure you will have to delete it when done). When core folder is uploaded with a php browser permitions for folders/files can be 755/644 and everything will be working perfectly.

              Another workaround is to place the core/packages with 777 outside the public_html folder with openbase_dir but in my short analysis that seemed dangerous too.

                • 34163
                • 11 Posts
                Stretched Reply #7, 11 years, 4 months ago
                Quote from: markh at Dec 08, 2012, 07:18 PM
                ...You can chown (change the owner) the directory (and its subdirectories) to the www-data user, and then you can set hte permissions back to 755.

                That's what I did in the end. I changed the owner & group of /core/components and /core/packages to www-data. The message disappeared and I can now download packages. There were a couple of other directories (e.g. /core/cache) that had to be changed too.