Trying to use the NFS plugin with a synced folder in Vagrant, and it is working, except that in the guest (VM) the permissions are wrong:
-rw-r--r-- 1 501 dialout 0 Jan 20 00:51 a
-rw-r--r-- 1 501 dialout 0 Jan 20 00:51 foo
I tried setting up the uid and gid according to the Vagrant documentation in the Vagrantfile:
config.nfs.map_uid = 1001
config.nfs.map_gid = 1001
Which I was hoping would use the correct user/group in the guest, but it is still using 501 and dialout.
Any ideas?
This worked for me on a MacOS Catalina host and Ubuntu 18.04 guest (Vagrant 2.2.9, VirtualBox 6.1.12):
opts = {
type: 'nfs',
linux__nfs_options: ['no_root_squash'],
map_uid: 0,
map_gid: 0
}
config.vm.synced_folder '.', '/var/www/project', opts
You can then chown and chmod as usual:
$ sudo chown -R vagrant:vagrant /var/www/project
$ sudo chmod -R 774 /var/www/project/logs
ATTENTION: no_root_squash is fine for development environments, but DON'T use it for production. It allows remote root users to change any file in the shared file system.
Another option might be to use the vagrant-bindfs plugin. But I didn't feel like installing and configuring an extra plugin for this.
I had the same issue. It started after I've upgraded my MacOS to mcOS Sierra version 10.12.1. The trick that worked for me was to set/force the owner and group to the 'vagrant' user in Vagrantfile like this:
config.vm.synced_folder "/users/myuser/src/", "/home/vagrant/src/", owner: "vagrant", group: "vagrant"
I also had to remove the 'nfs: true' setting that was previously there in the Vagrantfile.
Related
I use homestead and I have recently updated my application to Laravel 5.8.
Since then, I am getting permission errors whenever I try to login/logout.
The errors I'm getting are like the following:
UnexpectedValueException
The stream or file "/home/vagrant/Code/myapp/storage/logs/laravel-2022-04-11.log" could not be opened in append mode: failed to open stream: Permission denied
Here's an ll of my /storage/logs folder (without ssh into homestead):
drwxrwsrwx 2 username www-data 4096 Apr 12 01:32 ./
drwxrwsrwx 5 username www-data 4096 Oct 27 2020 ../
-rwxrwxrwx 1 username www-data 11700 Nov 28 21:25 laravel-2021-11-28.log*
-rwxrwxrwx 1 username www-data 5850 Feb 9 21:13 laravel-2022-02-09.log*
-rwxrwxrwx 1 username www-data 203687 Feb 13 22:58 laravel-2022-02-13.log*
-rwxrwxrwx 1 username www-data 19324 Apr 12 01:39 laravel-2022-04-11.log*
And here's an ll of my /storage/logs folder (with ssh into homestead):
drwxrwxrwx 1 vagrant vagrant 4096 Apr 11 22:32 ./
drwxrwxrwx 1 vagrant vagrant 4096 Oct 27 2020 ../
-rwxrwxrwx 1 vagrant vagrant 11700 Nov 28 19:25 laravel-2021-11-28.log*
-rwxrwxrwx 1 vagrant vagrant 5850 Feb 9 19:13 laravel-2022-02-09.log*
-rwxrwxrwx 1 vagrant vagrant 203687 Feb 13 20:58 laravel-2022-02-13.log*
-rwxrwxrwx 1 vagrant vagrant 19324 Apr 11 22:39 laravel-2022-04-11.log*
Notice that the users/groups are different.
Do not pay so much attention to the current permissions - nothing changes if I put the default permissions.
Now, let's say I try to login.
What will happen is that I will get the error I said in the beginning and the permissions for the last log file (the daily file for the current day) will change to this:
-rw-rw-r-- 1 vagrant vagrant 95308 Apr 11 22:48 laravel-2022-04-11.log
If I run:
sudo chmod -R 777 storage bootstrap/cache
then the permission of the file returns to:
-rwxrwxrwx 1 vagrant vagrant 95308 Apr 11 22:48 laravel-2022-04-11.log*
and when I refresh the page, the login has worked.
Obviously, the www-data user is trying to write something in the log file while trying to login and it fails because the permissions are not 777 (and they shouldn't be).
In my config/logging.php file I can see the following:
'daily' => [
'driver' => 'daily',
'path' => storage_path('logs/laravel.log'),
'level' => 'debug',
'days' => 14,
'permission' => 0664,
],
Notice the 'permission' => 0664 part. This is why the permissions of the file change when I try to login.
If I change this to 0777, it works but I get a permissions error in the /storage/framework/sessions directory.
Also, this should remain 0664 due to security considerations.
I have tried every answer on SO on this problem but nothing has worked.
My production server works fine (thankfully).
Any ideas??
It took me days to solve this, so here's what worked for me.
This is a Vagrant/Homestead issue.
When Homestead boots up, the correct permissions/owners should already be set; there is no way to change them later (neither from within -ssh- nor outside homestead).
According to Vagrant's DOC, we can use the Vagrantfile to set different permissions to certain directories.
What worked for me was to include the following in my Vagrantfile:
config.vm.synced_folder "/home/username/Code/myapp/", "/home/vagrant/Code/myapp", :owner => "www-data", :group => "www-data"
After adding this config, my project folders/files are owned by www-data in Homestead.
Some important notes:
The above config needs to go inside the Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| section of the Vagrantfile.
The first path (/home/username/Code/myapp/) is the path to your project directory on your host machine (ie. your pc) and the second path (/home/vagrant/Code/myapp) is the path inside your VM/Vagrant/Homestead environment.
Remember to provision after you make any changes.
You can verify that Homestead is using your changes by checking the output when you run homestead up --provision. Mine looks something like this:
==> homestead-7: Mounting shared folders...
homestead-7: /vagrant => /home/username/Homestead
homestead-7: /home/vagrant/Code => /home/username/Code
homestead-7: /home/vagrant/Code/myapp => /home/username/Code/myapp
The last line is the one we added.
This line homestead-7: /home/vagrant/Code => /home/username/Code is the default mapping which is configured on your Homestead.yaml file:
folders:
- map: ~/Code
to: /home/vagrant/Code
so, in my case, the Code directory has the default permissions and the Code/myapp directory has www-data as an owner.
You can set the permissions in as many directories as you want.
Question: how to create simple nginx config that will read folders structure as domains (test.local, myblog.local) and shows the page from this folders, including PHP?
Information:
Windows 10 x64 build
Vagrant 1.9.5
VirtualBox 5.0.22 (latest)
Guest OS: Ubuntu Xenial x64 latest
So, i want to create simple nginx config, that will recreate folder structure. See
my config file on pastebin.
Also here is a Vagrantfile config, which use SMB to mount a folder.
The structure of folders:
├───devhost.local
│ ├───log
│ └───public
│ index.html
│ index.php
│
└───test.local
├───log
└───public
index.html
The rights for files and folders for devhost:
ubuntu#ubuntu-xenial:~$ ls -la /var/www/html/devhost.local/
total 4
drwxr-xr-x 2 ubuntu www-data 0 Jun 7 11:17 .
drwxr-xr-x 2 ubuntu www-data 4096 Jun 7 12:44 ..
drwxr-xr-x 2 ubuntu www-data 0 Jun 7 11:17 log
drwxr-xr-x 2 ubuntu www-data 0 Jun 6 14:13 public
My hosts file in Windows:
192.168.33.10 devhost.local
So, when i have default config in my sites-enabled folder i can open guest machine through 192.168.33.10 and i see html page of nginx, but when i remove this default config and enable my wildcard config (see link my config file) so i cannot access my domains. The sudo nginx -t says that everything is ok, also i tried to restart my guest machine, reload/restart nginx service. Also, i disable Windows 10 Firewall (i dont know if its disabled fully, but says that its disabled). Also, the log files is empty and even not created, both access log and error log.
Where is my mistake? If need more information, please, ask me, i will give.
Thanks a lot!
following nginx setup should help.
server {
listen 80 default_server;
root /var/www/html/$host;
index index.html index.php;
location ~ \.php {
# ... fastcgi details
}
}
I found the solution.
First of all, when i keep only one file with config, my nginx doesnt listen port 80, i check sudo netstat -ntlp | grep LISTEN but there wasnt port 80. So i Google, and found another question on stackoverflow (see link at the end).
Solution: recreate the simlink to my file with config, after that when i run sudo nginx -t i see a few errors. So its seems that before this files was empty or something like that, but i didnt notice this because i edit file directly in sites-available folder.
Thanks to everybody!
This question helps me to solve the problem: nginx not listening to port 80
Currently I'm struggling with permission issues in my Drupal installation on a Drupal-VM (Vagrant + Virtual Box on Windows). I'm syncing with rsync which leads to owner and group vagrant of synced files and folders. Because apache is running with user www-data files cannot be written in in the public temp folder sites/default/files, which is owned by vagrant:vagrant. That's why I'm trying to change the group of synced files to www-data. How do I accomplish this?
My Environment
Vagrant 1.9.1
VirtualBox 5.1.14 r112924
My OS
Microsoft Windows [Version 10.0.14393]
Summary
I've already tried the following settings in config.yml:
vagrant_synced_folders:
- local_path: C:\#\myproject
destination: /var/www/myproject.dev
type: rsync
create: true
options_override:
group: www-data
or
vagrant_synced_folders:
- local_path: C:\#\myproject
destination: /var/www/myproject.dev
type: rsync
create: true
group: www-data
These don't take effect after vagrant reload. When I check .vagrant/machines/mydrupalvmbox/virtualbox/syncedfolders group is still vagrant. Changing the group in this temp file and doing a vagrant rsync results the correct group for rsynced files and directories. But after vagrant reload those temp settings are gone and group vagrant is back again.
I've also tried to change the group via rsync_args with no success:
vagrant_synced_folders:
- local_path: C:\#\myproject
destination: /var/www/myproject.dev
type: rsync
create: true
options_override:
rsync__args: [
"--verbose", "--archive", "--delete",
"--chmod=gu=rwX,o=rX",
"--group", # required for the following command
"--groupmap=*:www-data"
]
I get an error: Error: rsync: --groupmap=*:www-data: unknown option.
So what's the right setting?
which version of rsync are you running ?
The groupmap option has been included in version 3.1.0 (see https://rsync.samba.org/ftp/rsync/src/rsync-3.1.0-NEWS)
- Added the --usermap/--groupmap/--chown options for manipulating file
ownership during the copy.
upgrade your rsync version (if you're using cygwing, upgrade cygwin/rsync) and make sure you get an up-to-date version
rsync --version
In Drupal VM you have to use rsync__group inside of options_override:
vagrant_synced_folders:
- local_path: C:\#\myproject
// [...]
options_override:
rsync__group: www-data
See related issue: https://github.com/geerlingguy/drupal-vm/issues/1199
This might work in other vagrant boxes too.
In my Vagrantfile I have described a synced folder with liberal permissions as per the docs and sample box:
config.vm.synced_folder ".", "/var/www", :mount_options => ["dmode=777", "fmode=666"]
When I'm using the VM via vagrant ssh, any app/console attempt will return permission denied. Checking the entry on the VM, sure enough, the file is not executable:
-rw-rw-rw- 1 vagrant vagrant 867 Nov 13 12:11 console
However on the host I can see the file has correct permissions (OS X):
-rwxr-xr-x 1 chris staff 867 13 Nov 12:11 console
I presume the fmode=666 is stripping the executable bit.
If I change that, won't it set everything executable? Is there a way to mirror per-file permissions from the host while still changing the owner/group?
The value for file permissions are as following
4 read (r)
2 write (w)
1 execute (x)
so 6 corresponds to 4+2 (read + write) which is what you see so its consistent.
If you want to match your OS permission (rwxr-xr-x) you would need to set 755 as file mode
config.vm.synced_folder ".", "/var/www", :mount_options => ["dmode=777", "fmode=755"]
What is the difference between vagrant box repackage (docs) and vagrant package (docs)?
I realise that vagrant package works only with the VirtualBox provider, but in case only VirtualBox is used - what's the difference? Maybe there's a specific reason vagrant package was created?
vagrant package
If you have a running VirtualBox VM, you created without vagrant first, did your things using VirtualBox, and you now want to use Vagrant to manage this VM. As vagrant needs box to start VM, you will run vagrant package to create a vagrant box based on the existing VirtualBox VM
vagrant repackage
You will use this option when you have an existing vagrant box installed on your system. So you use vagrant with a given box, again you will make change to the VM and you want to save those changes (software installed ...) as a new box, you will run vagrant repackage on this box, and it will create an updated version of this box so it can be used as starting box for new VM.
I will answer with the specific example of the VirtualBox provider on macOS, but this can be generalized to any provider on any host. Although not asked by the op, I will also explain --base NAME because I think it helps in clarifying the difference. I will also use the --output OUTPUT_NAME to distinguish between the packaged boxes.
vagrant package
~/code/vagrant/vm1 > vagrant package --output vm1-package.box
Attempts graceful shutdown of currently running VM which is found from ./.vagrant/... directory
Clears any previously set forwarded ports
Exports the VM (using the provider's export tools) and adds vagrant_private_key
Archives (using tar) everything into ./vm1-package.box
==> vm1: Attempting graceful shutdown of VM...
==> vm1: Clearing any previously set forwarded ports...
==> vm1: Exporting VM...
==> vm1: Compressing package to: /Users/user/code/vagrant/vm1/vm1-package.box
To verify:
~/code/vagrant/vm1 > tar -C /tmp/vm1 -xvf ./vm1-package.box
x ./vagrant_private_key
x ./metadata.json
x ./box.ovf
x ./Vagrantfile
x ./box-disk001.vmdk
Since this packages the currently running VM that Vagrant manages, the above list includes the vagrant_private_key file (which is loaded by the packaged Vagrantfile).
Now, we can add this box to Vagrant's internal storage in ~/.vagrant.d:
~/code/vagrant/vm1 > vagrant box add vm1-package.box --name vm1
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'vm1' (v0) for provider:
box: Unpacking necessary files from: file:///Users/user/code/vagrant/vm1/vm1-package.box
==> box: Successfully added box 'vm1' (v0) for 'virtualbox'!
which you can also verify by:
~/code/vagrant/vm1 > ls -lF ~/.vagrant.d/boxes/vm1/0/virtualbox/
total 1152400
-rw-r--r-- 1 user staff 630 13 Dec 16:26 Vagrantfile
-rw-r--r-- 1 user staff 575710720 13 Dec 16:26 box-disk001.vmdk
-rwx------ 1 user staff 6838 13 Dec 16:26 box.ovf*
-rw-r--r-- 1 user staff 25 13 Dec 16:26 metadata.json
-rw------- 1 user staff 1675 13 Dec 16:26 vagrant_private_key
~/code/vagrant/vm1 > vagrant box list
hashicorp/bionic64 (virtualbox, 1.0.282)
vm1 (virtualbox, 0)
vagrant package --base vm_name
~/code/vagrant/vm1 > vagrant package --base vm1 --output vm1-base-package.box
Attempts graceful shutdown of currently running VM which is found from ./.vagrant/... directory
Clears any previously set forwarded ports
Exports the VM (using the provider's export tools) but does not add vagrant_private_key
Archives (using tar) everything into ./vm1-base-package.box
==> vm1: Exporting VM...
==> vm1: Compressing package to: /Users/user/code/vagrant/vm1/vm1-base-package.box
To verify:
~/code/vagrant/vm1 > tar -C /tmp/vm1-base -xvf ./vm1-base-package.box
x ./metadata.json
x ./box.ovf
x ./Vagrantfile
x ./box-disk001.vmdk
Since this packages the currently running VM that Virtualbox manages, the above list does not includes the vagrant_private_key file.
Now, we can add this box to Vagrant's internal storage in ~/.vagrant.d:
~/code/vagrant/vm1 > vagrant box add vm1-base-package.box --name vm1-base
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'vm1-base' (v0) for provider:
box: Unpacking necessary files from: file:///Users/user/code/vagrant/vm1/vm1-base-package.box
==> box: Successfully added box 'vm1-base' (v0) for 'virtualbox'!
~/code/vagrant/vm1 > vagrant box list
hashicorp/bionic64 (virtualbox, 1.0.282)
vm1 (virtualbox, 0)
vm1-base (virtualbox, 0)
~/code/vagrant/vm1 > ls -lF *.box
-rw-r--r-- 1 user staff 561848649 13 Dec 16:50 vm1-base-package.box
-rw-r--r-- 1 user staff 561767838 13 Dec 16:19 vm1-package.box
If you delete the box files from the current directory...
~/code/vagrant/vm1 > rm *.box
... you may now use vagrant repackage to get them back:
vagrant box repackage
~/code/vagrant/vm1 > vagrant box repackage vm1 virtualbox 0
This takes the files from Vagrant's internal storage ~/.vagrant.d/... and re-packages them back into a box in the current directory called package.box. In this case, you cannot name the file using the command, so you may want to rename it:
~/code/vagrant/vm1 > mv package.box vm1-package.box
and for the base box:
~/code/vagrant/vm1 > vagrant box repackage vm1-base virtualbox 0
~/code/vagrant/vm1 > mv package.box vm1-base.box
~/code/vagrant/vm1 > ls -lF *.box
-rw-r--r-- 1 user staff 561848571 13 Dec 17:28 vm1-base.box
-rw-r--r-- 1 user staff 561767855 13 Dec 17:24 vm1-package.box
Additional note
The manual is not very clear on the syntax of the vagrant package command with and without the --base option. I think the clarification should be:
vagrant package [options] [vm_name|vm_id]
It should specify that if [vm_name|vm_id] is not specified, then the currently running VM is packaged, otherwirse, the VM specified by [vm_name|vm_id] is packaged.
It should also specify that if you use the --base option, the command should be:
vagrant package --base MANDATORY_NAME [vm_name|id]
but in this case, [vm_name|id] is completely ignored, since the VM has already been specified by MANDATORY_NAME
I verified this by issuing:
vagrant package --base vm1 --output vm1-base-package.box non-existent-vm-name
and it still generated vm1-base-package.box without any errors.