symfony - Symfony2 Capifony deploy setfacl Operation not permitted on cache directory -
i deploying symfony2 web app onto apache web server, on ubuntu machine, hosted on aws, using capifony multistage deploy.
i have user set
set :user, "ubuntu"
and writable directory cache set so
set :writable_dirs, ["app/cache"] set :webserver_user, "www-data" set :use_set_permissions, true set :permission_method, :acl
everything deploying fine apart when run
executing "setfacl -r -m u:ubuntu:rwx -m u:www-data:rwx /var/www/releases/20140310012814/app/cache"
i multiple operation not permitted errors such as
setfacl: /var/www/releases/20140310012814/app/cache/prod/classes.php: operation not permitted
it seems user, presumably 'www-data', cannot set permissions on files created 'ubuntu'. however, have run following on server /var/www/current directory, i'm not entirely sure do:
sudo setfacl -r -m u:www-data:rwx -m u:`whoami`:rwx app/cache sudo setfacl -dr -m u:www-data:rwx -m u:`whoami`:rwx app/cache
here acl info
getfacl app/cache # file: app/cache # owner: ubuntu # group: ubuntu user::rwx user:www-data:rwx user:ubuntu:rwx group::rwx mask::rwx other::rwx default:user::rwx default:user:www-data:rwx default:user:ubuntu:rwx default:group::rwx default:mask::rwx default:other::rwx
i have had @ similar issue here should run similar? such as:
sudo sh -c 'setfacl -r -m u:ubuntu:rwx -m u:www-data:rwx /var/www/current/app/cache'
thanks
capifony has cookbook entry explaining how automatically set proper permissions. need this:
set :writable_dirs, ["app/cache", "app/logs"] set :webserver_user, "www-data" set :permission_method, :acl set :use_set_permissions, true
:use_sudo
doesn't need true
long :writable_dirs
owned :user
.
the problem
setfacl: /var/www/releases/20140310012814/app/cache/prod/classes.php: operation not permitted
this message indicates cache directory isn't empty when task run (setfacl
operates on prod/classes.php
in directory), not owned :user
(setfacl
not permitted).
the fact file not owned :user
quite normal because webserver create lot of cache files, make them owned :webserver_user
.
the strange thing here cache directory isn't empty. new release should have empty cache directory. common cause cache directory shared, meaning you've added :shared_children
. if so, please remove it. cache directory shouldn't shared.
if not case, try find out why cache directory isn't empty when setfacl
task run. maybe other tasks running soon.
writable shared children
what if want shared directory writable webserver? common, think of media
or uploads
directory should shared.
the permissions should set on actual shared directory, not symlink in release directory. capifony takes care of you, long exact same phrase in :writable_dirs
in :shared_children
.
# work: set :shared_children, ["web/uploads"] set :writable_dirs, ["web/uploads"] # work: set :web_path, "web" # default set :shared_children, [web_path + "/uploads"] set :writable_dirs, ["web/uploads"] # not: set :web_path, "web" # default set :shared_children, [web_path + "/uploads"] set :writable_dirs, ["web/uploads/"] # trailing /
please check if directory mentioned in error actual shared directory (not symlink).
the owner of shared directory must user run setfacl
command. in other words, must :user
. when you've changed value of :user
, or have had :use_sudo
enabled in past, cause issues. please check if directories (as set in :writable_dirs
) indeed owned :user
.
capifony perform check if permissions set. if so, won't try again. done following command:
getfacl --absolute-names --tabular #{dir} | grep #{webserver_user}.*rwx | wc -l"
try run command manually (replace #{dir}
, #{webserver_user}
actual values) see outcome. if yields no results, capifony assumes permissions have not yet been set, , try so.
in case, manually check permissions getfacl
. if indeed incorrect, manually set them (again, replace #{user}
, #{webserver_user}
, #{dir}
) using "the power of root":
sudo setfacl -r -m u:#{user}:rwx -m u:#{webserver_user}:rwx #{dir} sudo setfacl -dr -m u:#{user}:rwx -m u:#{webserver_user}:rwx #{dir}
then run capifony again. if well, should succeed time!
Comments
Post a Comment