cancel
Showing results for 
Search instead for 
Did you mean: 

Sticky Bit - Ignored or Misconfiguration?

Sticky Bit - Ignored or Misconfiguration?

I am attempting to run magento2 with a limited user named myuser from that myuser's home directory. User myuser is a member of the www-data group. I have created the working directories and set the sticky bit. To wit:

 

mkdir ~/myproject
chown -R :www-data ~/myproject
chgrp www-data ~/myproject
chmod g+s ~/myproject
find ~/myproject -type d -exec chmod g+s {} +
mkdir ~/myproject/html
unzip ../../Magento-CE-2.0.2-2016-01-28-02-20-20.zip -d
find . -type d -exec chmod 770 {} \; && find . -type f -exec chmod 660 {} \; && chmod u+x bin/magento
magento setup:install --base-url=http://myproject-dev.mydomain.com/ \
--cleanup-database --db-host=myuser.c6nkgccfgqyk.us-east-1.rds.amazonaws.com --db-name=myproject --db-user=myuser --db-password=ultramegasecret \
--admin-firstname=Phu --admin-lastname=Barr --admin-email=PBarr@MyDomain.net --admin-user=phubarr --admin-password=br549 \
--language=en_US --currency=USD --timezone=America/New_York --use-rewrites=1 \
--use-secure=1 --base-url-secure=https://myproject-dev.mydomain.com/ --use-secure-admin=1
find . -not -user myuser -printf "%p %u\n"
find . -not -group www-data -printf "%p %u\n"

 

All files and directories created with magento cli have proper user:group and everything has correct permssions. All is pure, I float on a lotus flower and eat a delicious pomegranate.

 

Then the worms came.

 

I browsed to https://myproject-dev.mydomain.com

  

$ find . -not -user myuser -printf "%p %u\n" | cut -d"/" -f1-3 | sort -u
./pub/static
./var/cache
./var/generation
./var/page_cache

 

User found is "www-dev", which is not expected.

 

When I then perform

 magento setup:static-content:deploy

I see awesome dots and 0 errors.

 

I refresh the page and see a nice Luma theme, so I'm feeling like this whole "wrong user" problem is something I can live with. Then, a numinous sense of dread.

 

$ find . -not -group www-data -printf "%p %u\n" |wc -l
0

Nope, that's okay. Let's change to production mode and see what happens.

 

magento deploy:mode:set production
Enabled maintenance mode
Static content deployment start
-snip-
New version of deployed files: 1456175562
Static content deployment complete
Start compilation
-snip-
Generated classes:
Magento\Sales\Api\Data\CreditmemoCommentInterfacePersistor
Magento\Sales\Api\Data\CreditmemoCommentInterfaceFactory
Magento\Sales\Api\Data\CreditmemoCommentSearchResultInterfaceFactory
Magento\Sales\Api\Data\CreditmemoComment\Repository
-snip-
On *nix systems, verify the Magento application has permissions to modify files created by the compiler in the "var" directory. For instance, if you run the Magento application using Apache, the owner of the files in the "var" directory should be the Apache user (example command: "chown -R www-data&colon;www-data <MAGENTO_ROOT>/var" where MAGENTO_ROOT is the Magento root directory).
Compilation complete
Disabled maintenance mode
Enabled production mode.

 

Aw shoot. Well, it's not all red and flashing, maybe it's not so bad . . .

 

find . -not -group www-data -printf "%p %u\n" | cut -d"/" -f1-3 |sort -u
./pub/static

GROUP found is "myuser", which is not expected.

 

So, to summarize:

 

I expect all directories and files in ~/myproject to retain the user/group myuser:www-data.


On first refresh in development mode the directories

 

./pub/static
./var/cache
./var/generation
./var/page_cache

 

are created with the USER "www-data"

On switching to production mode, the contents of the directory


./pub/static

 

are created with the GROUP "myuser", which, of course, is a cascade of 404's due to bad group permissions.

 

This is not good.

 

I did not expect the first, since the sticky bit is set.
I would have expected the sticky bit to have taken care of the second issue as well.

If I am doing something wrong in my configuration, I'd love to know what.

If I am doing something incompatible with running magento2 (i.e. not from /var/www or whatever it's been mainly tested in) I'd love to know that, too.

 

3 REPLIES 3

Re: Sticky Bit - Ignored or Misconfiguration?

Follow-up: before anyone suggests the "work-around" of simply scripting user:group ownership changes, that's a work-around. I want to know if this is a bug, or if my configuration is in a state of sin and I just don't know it.

Re: Sticky Bit - Ignored or Misconfiguration?

Nice to see I am not going crazy. Having the same or similar issues. Someone?

Re: Sticky Bit - Ignored or Misconfiguration?

This question has gotten only one reply. The reply was "yep, same here". I'm new to these forums and wonder if:

 

1. My set-up (userspace/nginx/relying exclusively on cli tools) is a corner case

2. I put way too much information in my post, causing eye-glazing

3. I've asked the question in such a way that I've broken some unwritten rule and am therefore being righteously shunned until I come to my senses :-D

 

This is a serious request for information, though. Did I mess this post up somehow?