Complete installation in Setup: setting permissions on phantom folders

[SecondeJK]

Use the following commands for Linux:

rm -rf app/cache/*
rm -rf app/logs/*
HTTPDUSER=`ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\  -f1`
sudo setfacl -R -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX app/cache app/logs uploads uploads/* web/uploads web/uploads/* app/data
sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX app/cache app/logs uploads uploads/* web/uploads web/uploads/* app/data
Or these commands for Mac OSX:

rm -rf app/cache/*
rm -rf app/logs/*
HTTPDUSER=`ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\  -f1`
sudo chmod +a "$HTTPDUSER allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs uploads uploads/* web/uploads web/uploads/* app/data
sudo chmod +a "`whoami` allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs uploads uploads/* web/uploads web/uploads/* app/data
Or these commands for Windows (with IIS web server):

rd app\cache\* -Recurse -Force
rd app\logs\* -Recurse -Force
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule -ArgumentList @("IUSR","FullControl","ObjectInherit, ContainerInherit","None","Allow")
$folders = "app\cache", "app\logs", "app\data", "uploads", "uploads\*", "web\uploads", "web\uploads\*"
foreach ($f in $folders) { $acl = Get-Acl $f; $acl.SetAccessRule($rule); Set-Acl $f $acl; }

Regarding these lines to set permissions - despite changing to master to deploy, attempting on MacOS to set permissions on the following throws errors:

chmod: Failed to set ACL on file 'uploads': No such file or directory
chmod: Failed to set ACL on file 'uploads/*': No such file or directory
chmod: Failed to set ACL on file 'web/uploads': No such file or directory
chmod: Failed to set ACL on file 'web/uploads/*': No such file or directory
chmod: Failed to set ACL on file 'app/data': No such file or directory

Is there any reason why we're setting permissions for folders that don't yet exist straight out of the box? I mean, we might later, but not now?

[alexander-schranz]

If I remind correctly after composer install/update the symfony cache is cleared and after this the folders should exist.

[SecondeJK]

The folders certainly aren't there after a composer install

[SecondeJK]

The folders aren't there after doing a composer update, either. On doing a composer update, the lock file seems to be trying to pull the old guzzle/guzzle repo instead of guzzlehttp/guzzle. Maybe that's a PR though

[danrot]

Probably also related to https://github.com/sulu/sulu/issues/2567

[danrot]

@SecondeJK The folders you are mentioning here should exist after composer install, because they are created with the composer script handlers. What's the end of the output of composer install? Should be something like this:

> Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installRequirementsFile
> Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::prepareDeploymentTarget
> Sulu\Bundle\MediaBundle\Composer\MediaScriptHandler::initBundle
Create media dirs in /Users/daniel/Temporary/sulu-standard
Create Upload dir in /Users/daniel/Temporary/sulu-standard/app/../uploads/media
Create Media Cache dir in /Users/daniel/Temporary/sulu-standard/app/../web/uploads/media
> Massive\Bundle\SearchBundle\Composer\SearchScriptHandler::initBundle

Do you see any errors instead?

[SecondeJK]

This may need to be closed as repeating the process caused no problems - it's more likely that composer was doing something strange....absolutely no idea what though. I'm also using something else now as I encountered about 2 days of gotchas and got bored :(

[danrot]

That's too bad... But you got Sulu running now? What about https://github.com/sulu/sulu-standard/issues/721? Is that also no issue anymore?