I am developing symfony inside of a vagrant box. Recently I tried to boost performance (10k latency) and found this article.
It is suggesting to use /dev/shm/ for cache and logs.
This works like a charm, but comes with a problem. Lets say, I create the assets. Then the created files belong to the wrong user, because I am logged in as a vagrant user.
[05:33 ]-[vagrant#machine1]-[/var/www/backend]-[git dippingbird/master]
$ ls -lsah /dev/shm/appname/
total 0
0 drwxrwxr-x 4 vagrant vagrant 80 Mar 21 05:28 ./
0 drwxrwxrwt 3 root root 80 Mar 21 05:28 ../
0 drwxrwxr-x 3 vagrant vagrant 60 Mar 21 05:28 cache/
0 drwxrwxr-x 2 vagrant vagrant 60 Mar 21 05:29 logs/
When I want to visit the page in dev environment, it clearly does not work. It says in the browser:
If I change the permissions to -R 777 it clearly works.
So I figured out, that I want apache run as the vagrant user. But internet documentation is vague. I want to do it via my puphpet config.yaml so it is available for all developers in the team.
Or do I have a braintwist? Why is this permission error not occuring when I am using the dirname(__DIR__).'/var/logs'; for logs / cache.
Related
I know my question is similar to old ones answered many times. But stil, I don't understand why the following behavior. I'm on centos 7.9 with php 5.4.16.
Being the user, I can execute mkdir('/tmp/mydir', 0775) correctly
drwxrwxr-x 3 john john 60 20 déc. 09:30 mydir
When excuting as apache with sudo -u apache the php script either on CLI or with as an http request, I end up with
drwxr-xr-x 3 apache apache 60 20 déc. 09:22 mydir
And a sudo -u apache with chmod('./depth1',0775); works. The behaviour is similar when I do this is a directory that I own where apache has write mode or even in a directory belonging to apache. The fact that I belong to apache group, and apache belongs to my group does'nt change either when making the test in a directory I own and where group has write rights.
I am trying to self host a PHP script called sngine. (facebook clone)
When trying to install it I get an error:
config.php - Required includes folder to be writable for the installation
when I run ls -l I get this: drwxrwxrwx 5 mbeck mbeck 4096 Aug 25 23:00 includes
I don't know why it is saying that it's not writable.
The script is in var/www/{domain name}/
I am on Apache/2.4.41 (Ubuntu) and PHP version: 7.4.22
EDIT:
I found someone saying to run chown www-data:www-data <directory> So I did, and permissions now return drwxrwxrwx 5 www-data www-data 4096 Aug 25 23:00 includes and the error is still there.
Ok, I found it!
I had to run sudo chown -R www-data /var/www/example.com/mydomain/includes/
Now it works!
I know that it is impossible to change the permissions of a file shared via volume, because a matter of default, and from what I understand, the permissions of the docker container, reflect the permissions of the host, however, this is not happening in my case, the docker simply changes permissions on all files to 755, and some files must have specific permissions.
HOST:
Docker Container:
Docker File:
FROM ubuntu:18.04
ARG DEBIAN_FRONTEND=noninteractive
#Updating operating system
RUN apt-get update && apt-get -y upgrade && apt-get -y dist-upgrade
##Installing essential packages
RUN apt-get -y install apt-utils software-properties-common curl bash-completion vim git supervisor
## Add Scripts
ADD ./start.sh /start.sh
EXPOSE 80
STOPSIGNAL SIGTERM
#CMD ["/start.sh"]
ENTRYPOINT echo $XDEBUG_CONFIG >> /etc/php/7.3/fpm/php.ini && service php7.3-fpm start && nginx -g "daemon off;"
docker-compose.yml
volumes:
- ${DOCUMENT_ROOT-./www}:/usr/share/nginx/html
- ${VHOSTS_DIR-./config/nginx/sites-enabled}:/etc/nginx/sites-enabled
- ${PHP_INI-./config/php/php.ini}:/etc/php/7.3/fpm/conf.d/php.ini
- ${LOG_DIR-./logs/nginx}:/var/log/nginx
Your assumption
I know that it is impossible to change the permissions of a file shared via volume
Is only partially correct, there is actually a set of modes — :ro & :rw – you can use when mounting a volume via docker-compose that are described in the documentation:
Standard modes are ro for read-only and rw for read-write (default).
Source: https://docs.docker.com/compose/compose-file/#short-syntax-3
You can also use the :Z and :z modes if your host uses selinux.
If you use selinux you can add the z or Z options to modify the selinux label of the host file or directory being mounted into the container. This affects the file or directory on the host machine itself and can have consequences outside of the scope of Docker.
The z option indicates that the bind mount content is shared among multiple containers.
The Z option indicates that the bind mount content is private and unshared.
Use extreme caution with these options. Bind-mounting a system directory such as /home or /usr with the Z option renders your host machine inoperable and you may need to relabel the host machine files by hand.
Source: https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label
Here is an example, on my host, here are the permissions of my files:
~ # ls -la ro rw
ro:
total 0
drwxr-xr-x 3 ben staff 96 May 23 23:06 .
drwxr-xr-x 9 ben staff 288 May 23 23:16 ..
-rw-r--r-- 1 ben staff 0 May 23 23:06 file
rw:
total 0
drwxr-xr-x 3 ben staff 96 May 23 23:06 .
drwxr-xr-x 9 ben staff 288 May 23 23:16 ..
-rwxr-xr-x 1 ben staff 0 May 23 23:06 file
Then with this docker-compose.yml
version: '3.8'
services:
test:
image: alpine
volumes:
- ./ro:/root/ro:Z
- ./rw:/root/rw:Z
command: sleep 100000000000
Here is the result on the container
~ # ls -la ro rw
ro:
total 4
drwxr-xr-x 3 root root 96 May 23 21:06 .
drwx------ 1 root root 4096 May 23 21:17 ..
-rw-r--r-- 1 root root 0 May 23 21:06 file
rw:
total 4
drwxr-xr-x 3 root root 96 May 23 21:06 .
drwx------ 1 root root 4096 May 23 21:17 ..
-rwxr-xr-x 1 root root 0 May 23 21:06 file
I know this question is asked a lot, but I can't seem to find the error why my symlinks sometimes aren't working.
I have two folders:
/home/user/domains/example.com/folder1
/home/user/domains/example.com/folder2
These are their permissions:
drwx--x--x 9 root root 4096 May 12 11:15 home
drwx--x--x 7 user access 4096 Feb 9 10:23 user
drwx--x--x 3 user user 4096 May 5 2014 domains
drwx--x--x 12 user user 4096 Jul 7 09:52 example.com
drwxr-xr-x 2 apache apache 4096 Jan 21 09:22 folder1
drwxrwxrwx 4 user user 4096 Jul 9 10:38 folder2
in PHP I create two symlinks:
symlink("/home/user/domains/example.com/folder1","whatever/folder");
symlink("/home/user/domains/example.com/folder2","whatever/folder");
Why is my symlink to folder1 working and my symlink to folder 2 not? I have been looking at it for hours now..
Edit:
Well, as my provider isn't of any help, I'd like to try a different solution: create a symlink and immediately change its owner. This, however, gives me an 'Operation not permitted' error. Any ideas on that?
Assuming the symbolic links were created successfully, folder2 most likely yields a permission error when Apache is configured to only follow symbolic links if the owner matches; you're looking for this specific configuration option:
SymLinksIfOwnerMatch
You could make Apache less rigid by using the following option instead:
FollowSymLinks
Alternatively, fix the ownership of the symbolic link target to make it work.
Try to delete both symlinks then 1) try PHP again and see if it persists and 2) logging in via SSH and create the same links using ln instead, for example
ln -s whatever/folder /home/user/domains/example.com/folder1
If that works, then it is probably a permission issue with the folder you are linking from or into, that the apache server / PHP cannot address
Does whatever/folder have enough permissions?
Remove folder1 and folder2 then Try
symlink("/home/user/domains/example.com/folder1.txt","whatever/folder");
Change the user group of folder2 from user:user to apache:apache
chown -R apache:apache folder2
The reason is because Apache needs the group permissions rather than a normal user.
Overview
I'm using Laravel 4.2 with an image upload feature. I have it set up on Homestead, but recently I removed Nginx and serve the site with Apache instead (due to the need to use Server Sent Events).
Before I moved from Nginx to Apache the file upload functionality worked fine. It also works fine on a staging server with Apache.
The Error
I'm using the Intervention image library to handle image uploads. When I try to upload a file, I get the following in my laravel.log file:
Can't write image data to path (/home/vagrant/projects/projectname/public/assets/pics/profile/photos/f55f0ae2-2d1a-4fdd-b9be-39d8a509baa3.jpg)
What I've Tried
I thought it was just a simple permissions error. I've gone so far as to chmod my asset directories to 0777, change the directory owner to www-data, create a new group called web with www-data and change the owner group to that, (basically everything in this answer and more) and still it doesn't work.
The directory definitely exists, and like I mentioned, it worked before the move to Apache (I'm not entirely sure if it's related but it seems likely).
My /var/log/apache2/error.log is empty, too.
The staging server works fine, but I don't want to encounter the same problem when I provision the production server. I'd like to fix the problem and understand it more so I can fix it if I ever come across it in the future. Why is this happening and what can I do to fix it/debug further?
Example Folder Permissions
drwxr-xr-x 1 vagrant vagrant 272 Jan 26 11:07 assets/pics
drwxr-xr-x 1 vagrant vagrant 170 Jan 26 10:11 assets/pics/defaults
drwxr-xr-x 1 vagrant vagrant 714 Jan 26 14:10 assets/pics/forums
drwxr-xr-x 1 vagrant vagrant 646 Jan 26 14:10 assets/pics/forums/thumbs
drwxr-xr-x 1 vagrant vagrant 170 Jan 20 18:02 assets/pics/gallery
drwxr-xr-x 1 vagrant vagrant 3026 Jan 26 13:24 assets/pics/messages
drwxr-xr-x 1 vagrant vagrant 2992 Jan 26 13:24 assets/pics/messages/thumbs
drwxr-xr-x 1 vagrant vagrant 136 Jan 8 17:27 assets/pics/profile
drwxr-xr-x 1 vagrant vagrant 136 Feb 10 14:48 assets/pics/profile/photos
drwxr-xr-x 1 vagrant vagrant 102 Feb 10 14:51 assets/pics/profile/photos/thumbs
For some reason the owner/group is still vagrant, even when I chown them. I've tried with sudo chown and by doing sudo -s.
Try modifying your Vagrantfile to include this line, before the end of the Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| block:
config.vm.synced_folder "/path/to/laravel/app", "/home/vagrant/projects/projectname", :owner => "www-data", :group => "www-data", :mount_options => ["dmode=775", "fmode=664"]
The string "/path/to/laravel/app" must point to dir you're working on outside the Vagrant machine. This should force the file owner and permissions to be the ones you specify for all the project files (so they're not overridden by vagrant). You'll need to restart the VM after you make the change.
How are you doing your chown? It should be
chown USERNAME GROUP -R /path/to/file