We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 17673
    • 194 Posts

    I just installed ModX a few hours ago and started playing with it; I keep getting lots of warnings:

    >Upload feature inhibited - make sure uploads are supported and the directory is writable for PHP

    ...I wander what the correct unix permissions should be, right now I have 755 on the modx general directory, on assets and all its subdir;

    changing to 775 does not solve the issue, going 777-wordWritable is surely not right

    the files are owned by the user ’www’ and by group ’INGV’ while Apache is running has ’nobody’ of group ’nobody’; is this the point ?!?

      ----------------------------------------------------------
      http://www.linkedin.com/in/lucapost/
      http://www.twitter.com/lukwe/
      ----------------------------------------------------------
    • You’ll need to go 777.
        Ryan Thrash, MODX Co-Founder
        Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
        • 1764
        • 680 Posts
        There are just a few directories that need to have 777 permissions. The ones I remember are assets/cache/, assets/cache/siteCache.idx.php, assets/cache/sitePublishing.idx.php, assets/images/, assets/files and assets/export/. Of course the don’t need to have 777 permissions if you set the ownership up right but 777 is the easy way.

        I would definitely discourage setting global 777 permissions. Big security issues there, especially on manager/includes/config.inc.php. The config file has the username and password to your database so you should set it as readable only by nobody (or whatever user your php install runs as) and not even readable to the world.
        • The best solution is to compile Apache with phpSuExec and run in CGI server API mode (also known as FastCGI). This allows your scripts to run as the user who owns the files, and no permission changes are required. It’s just as fast in my experience, as running in the Apache server API mode (mod_php), and infinitely more secure. Of course, that’s not always an option, so just changing permissions on the directories/files Adam described is the next best solution.
            • 17673
            • 194 Posts
            >The best solution is to compile Apache with phpSuExec and run in CGI server API mode (also known as FastCGI)

            thanks for the input -I’ll check with collegues, but I fear this would affect some other services on the server...

            I’ll go the ’Adam way’ and keep only those subdir in ’assets’ set to 777; is this standard or would I be better off to reinstall and have PHP, Apache, and Modx matching each other usr and group ?!


            ciao!
              ----------------------------------------------------------
              http://www.linkedin.com/in/lucapost/
              http://www.twitter.com/lukwe/
              ----------------------------------------------------------
            • Quote from: lukwe at Feb 23, 2006, 09:05 AM

              thanks for the input -I’ll check with collegues, but I fear this would affect some other services on the server...

              I’ll go the ’Adam way’ and keep only those subdir in ’assets’ set to 777; is this standard or would I be better off to reinstall and have PHP, Apache, and Modx matching each other usr and group ?!

              The 777 way is very standard on shared hosting situations; just doesn’t offer the best security. I just mentioned the FastCGI approach, because it does offer additional security and is a popular trend with some shared hosts these days in efforts to thwart exploits with popular scripts.
              • An interesting article on the subject.

                http://www.trilithium.com/johan/2005/04/apache2-fastcgi/
                  Studying MODX in the desert - http://sottwell.com
                  Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                  Join the Slack Community - http://modx.org