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"]
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.
I have a CentOS 7 vagrant. When I try to use nfs for sharing a folder the folder gets owned by the user 501 of the "games" group:
[vagrant#site-dev ~]$ ls -la
total 28
drwx-----x. 6 vagrant vagrant 180 feb 27 21:18 .
drwxr-xr-x. 3 root root 21 dic 15 11:14 ..
drwxrwxr-x. 3 vagrant vagrant 17 feb 24 17:46 .ansible
-rw-rw-r--. 1 vagrant vagrant 17 feb 27 20:46 app.php
-rw-------. 1 vagrant vagrant 4811 feb 27 21:47 .bash_history
-rw-r--r--. 1 vagrant vagrant 18 dic 6 23:19 .bash_logout
-rw-r--r--. 1 vagrant vagrant 193 dic 6 23:19 .bash_profile
-rw-r--r--. 1 vagrant vagrant 231 dic 6 23:19 .bashrc
-rwxrwxrwx. 1 vagrant vagrant 0 feb 27 20:49 index.html
drwxrwxr-x. 2 vagrant vagrant 78 feb 24 18:17 .phpstorm_helpers
drwx------. 2 vagrant vagrant 29 feb 24 17:45 .ssh
drwxrwxrwx. 22 501 games 748 feb 27 21:47 www
The strange thing is that if I remove the nfs option from the Vagrantfile then I don't have that problem (but performance drops)
Here's my Vagrantfile config without the nfs option
Vagrant.configure(2) do |config|
config.vm.box = "centos/7"
config.vm.network "forwarded_port", guest: 80, host: 8088
config.vm.network "private_network", ip: "192.168.56.150"
config.vm.hostname = "site-dev"
config.vm.synced_folder ".", "/home/vagrant/www"
config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--memory", "2048"]
end
config.vm.provision :ansible do |ansible|
ansible.playbook = "ansible/playbook.yml"
ansible.verbose = 'vvv'
ansible.inventory_path = "ansible/hosts"
ansible.limit = 'development'
end
end
Any idea why this is happening and how I can use nfs for the shared folder?
It should not be much of an issue - Mitchell explains here
NFS works by simply shuttling files and metadata over from server to
client, which means permissions can't be changed mid-way. I've
configured NFS by default to the common-case, which is that even
though the uid/gid is 501/20, every user on the VM should be able to
write to it (go ahead, try it!).
In practice, this has never been a problem for serving any web
applications.
If you really want to have correct username shows in ls command you can look at the vagrant bindfs plugin
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.
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.
I want to migrate a big project (5000 files) to vagrant with virtualbox.
Virtualbox shared folders is known to be slow for big project, so I want to use NFS.
But, I don't find the right way to use NFS instead of the default shared folder issue. It works when I put code in another folder, and share it. But I want to integrate Vagrant in the current one.
config.vm.synced_folder '.', '/vagrant', nfs: true
doesn't work:
exportfs: duplicated export entries:
exportfs: 10.11.12.13:/home/vincent/workspace/gp
exportfs: 10.11.12.13:/home/vincent/workspace/gp
Any idea to solve this strange issue?
Thank you.
Update 1
Same error with these parameters
config.vm.synced_folder ".", "/vagrant", disabled: true
config.vm.synced_folder ".", "/home/vagrant/gp", nfs: true
Here is the full error stack:
nfsd running
exportfs: duplicated export entries:
exportfs: 10.11.12.13:/home/vincent/workspace/gp
exportfs: 10.11.12.13:/home/vincent/workspace/gp
==> default: Mounting NFS shared folders...
Vagrant::Errors::LinuxNFSMountFailed: The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mount -o 'vers=3,udp' 10.11.12.1:'/home/vincent/workspace/gp' /home/vagrant/gp
Stdout from the command:
Stderr from the command:
stdin: is not a tty
mount.nfs: access denied by server while mounting 10.11.12.1:/home/vincent/workspace/gp
You may need to explicitly disable the default synced folder by adding the following line in your Vagrantfile so as to mount the NFS share to /vagrant
config.vm.synced_folder ".", "/vagrant", disabled: true
After than do a vagrant reload and see if it works.
In addition, consider using rsync type synced folder for your use case, I think it works even better. See https://docs.vagrantup.com/v2/synced-folders/rsync.html
You can also get this error message if you are trying to create a vm in a directory above another previously created vm. You will need to destroy the the vm's in each sub-directory.