I am attempting setup of a dev environment using Virtualbox on OSX host running Ubuntu Server 16.10 on guest.
I am stuck on getting Samba to share the dev directory on the guest so that ultimately Netbeans can be used to edit the server files on OSX via the share directory.
This works fine on OSX to seperate physical Ubuntu machine.
From standard Samba config, at the end is
[testsharename]
path=/home/myusername/shared#note trailing slash required
#hosts deny=*
#hosts allow=192.168.0.210#ip of an allowed lan address
guest ok=yes
writeable=yes
The actual share is identified using Finder on OSX however on clicking on it there is an error that it cannot be found. Changing the share name reflects on Finder. The commented out lines are because I only really want a single Lan IP to access.
Finder error is that the operation can't be completed because the original item for "testshare" can't be found
Logs showed Can't mount Samba share (canonicalize_connect_path failed) therefore some research narrowed this down to a permissions issue hinted at by https://ubuntuforums.org/showthread.php?t=1439582
Moving the share out of the home directory into /var/www/ as I originally required (the home directory part was simply testing things) this, with 777 permissions on the share dir only showed it to work perfectly.
I certainly don't agree from the forum post that all path nodes leading to the share require permission changes however.
Related
So I have an interesting issue that I just can't figure out why I'm getting this and what to do.
So basically I store all my development projects on my Synology NAS for local access between my various devices. There has never been a problem with this until I started playing around with Elixir and more importantly Phoenix. The issue I am getting is when running mix phx.server. I get the following
[warn] Phoenix is unable to create symlinks. Phoenix' code reloader will run considerably faster if symlinks are allowed. On Windows, the lack of symlinks may even cause empty assets to be served. Luckily, you can address this issue by starting your Windows terminal at least once with "Run as Administrator" and then running your Phoenix application.
[info] Running DiscussWeb.Endpoint with cowboy 2.7.0 at 0.0.0.0:4000 (http)
[error] Could not start node watcher because script "z:/elHP/assets/node_modules/webpack/bin/webpack.js" does not exist. Your Phoenix application is still running, however assets won't be compiled. You may fix this by running "cd assets && npm install".
[info] Access DiscussWeb.Endpoint at http://localhost:4000
So I tried as it stated and ran it in CMD as admin but to no avail. After some further inspection I tried to create the symlinks manually but every time I tried I would get a Access is denied. error (yes this is elevated CMD).
c:\> mklink "z:\elHP\deps\phoenix" "z:\elHP\assets\node_modules\phoenix"
Access is denied.
So I believe it is something to do with the fact that the symlinks are trying to be created on the NAS because if I move the project and host it locally it will work. Now I know what you're thinking. Yes, I could just store them locally on my PC but I like to have them available between PCs without having to transfer files or rely on git etc. (i.e. offline access), not to mention that the NAS has a full backup routine.
What I have tried:
Setting guest read write access on the SMB share
Adding to /etc/samba/smb.conf on my Synology NAS:
[global]
unix extensions = no
[share]
follow symlinks = yes
wide links = yes
Extra logging on SMB to see what is happening when I try it (nothing extra logged)
Creating a symbolic link from my MAC (works)
Setting all of fsutil behavior query SymlinkEvaluation to enabled
At the moment I am stuck and unsure of what to try next, or even if it is possible. Considering just using NFS instead but will I face the same issues with SMB?
P.S I faced a similar issue with Python venvs a while ago, just a straight-up Access is denied. error and just gave up and moved just the venv locally and kept the bulk of the code on the NAS. (This actually ended up beingthe best solution for that because the environments of each device on my network clashed etc.)
Any ideas are greatly appreciated.
I just installed Ubuntu 17.10 and I want to try create a website using Laravel, but I hit a rock, I followed the instructions. step by step on the official website. But I think something is missing,
Because I haven't touch / edit anything in Homestead.yaml, so basically it would working right?
I already use vagrant up --provision. already create the ssh key. I already googled it and try several ways but it doesn't fix it, I already turn on my XAMPP as well
Sorry but I never touched Ubuntu before, so I'm very blind using this OS
Here is my Homestead.yaml file
Homestead.yaml
and the directories of /home/workspace/ and /home/workspace/Homestead/
~ Dir
Homestead Dir
my Hosts file
Hosts File
EDITED:
I just create a new project in ~/Homestead/Projects/[it goes here] because the default laravel installation is working already, so now I want to create a new project in Projects folder inside Homestead, but why it redirect the url to https?
The folders
in this screenshot: https://i.stack.imgur.com/4cxGy.png Your ~/code folder appears to not exist, which means Homestead will not map it. Create that folder in your Host OS (Ubuntu 17) and then run vagrant destroy && vagrant up If you still have issues post the entire output here for us to check.
For my last question, why when I tried to open my new projects is always giving me this error your internet connection is not private. it's because I'm using .app or .dev in the of the site name, the problem is from google chrome, so I need changed it to .test then it's working perfectly.
I got the answer from this site
https://laracasts.com/discuss/channels/laravel/chrome-blocked-localhost-with-error-your-connection-is-not-private
First, I am on a Mac. Second, I have a virtualbox VM which was created using vagrant and which uses a shared folder to easily pass files back and forth, etc.
I would now like to clone this VM from a particular state so that I can upgrade an application on it and move forward with it. The issue is that the only way I know of to use shared folders here is to start the box using vagrant up (this makes sense as vagrant mounts the folders as part of its boot process); however, using vagrant up always triggers the original VM.
Is there a way to create a clone of a VM using Virtual Box and then to be able to use shared folders so I can easily copy files to and from the host and guest via ssh?
Did some more researching and found that I can mount a shared folder in a clone in the same way I can with the original virtualbox VM using:
mount -t vboxsf -o rw,uid=33,gid=33 <shared_folder_name> <guest_folder>
Note that the uid and gid specified here relate only to Debian-based systems. CentOS IDs are different.
For more on the technique and for solutions for CentOS boxes, see here: http://jimmybonney.com/articles/configure_virtualbox_shared_folder_apache_virtual_host/
I've tried the steps in the above article to allow for auto mounting the shared folder when the VM boots, but I've had no success. As a work-around (which I find acceptable for now), I created an alias in my .bashrc file which seems to work fine.
I would now like to clone this VM from a particular state so that I can upgrade an application on it and move forward with it
one thing you can look is vagrant snapshot
Snapshot works with VirtualBox provider to take a snapshot of your VM at the particular point of time when snapshot is taken. You can then continue working on your VM and when needed you can easily recover from a previous snapshot
I'm using Vagrant on two machines (home and office) with my working directories stored in Dropbox. I regularly run into the pronblem:
The VirtualBox VM was created with a user that doesn't match the
current user running Vagrant. VirtualBox requires that the same user
be used to manage the VM that was created. Please re-run Vagrant with
that user. This is not a Vagrant issue.
This is easily solved, brute-force, by rm -rf .vagrant, but I'd like to find a more elegant solution -- like an easily automated way to put the .vagrant files elsewhere.
Update
Here's the scenario: a working directory shared between office and home machine via Dropbox.
I vagrant up on office machine, successfully.
I shut down office machine and go home.
I get the message about on vagrant up, saying the id values aren't the same as when I created. (503 vs 501 in general)
I do rm -rf .vagrant and do vagrant up again, successfully.
When I go back to the office, same problem.
On the original issue
I get the message about on vagrant up, saying the id values aren't the
same as when I created. (503 vs 501 in general)
you can fix it by editing your UID in the following file .vagrant\machines\default\virtualbox\creator_uid and changing the 501/503 to a 0. (0 means you run as sudo)
But I think another issue that will pop up is that each of your machines is creating its own VM and stores it under your /Users/user/Documents/Virtual Machines and you're not sharing those files.
when you create a VM using VirtualBox, vb will assign the VM and id - this id is key and will make the link between vagrant and vb. As you create 2 different VMs, the VM have different Id and vagrant is not able to switch between the 2.
Hope this is clear so far, but how to go from there - you would have couple of options:
apparently you don't mind much about the content of the VM (as you do rm -rf so you recreate the VM each time you switch computer) so you can create a .vagrant.home and .vagrant.office and switch the .vagrant to point to the corresponding folder when you change machine so at least you don't need to recreate the VM, you can just start the VM from the corresponding computer. This is not ideal but will work.
you can avoid switching the .vagrant directory from above points by setting the env variable VAGRANT_CWD so you will not store the .vagrant directory under your dropbox account but you can have a script that export this variable and store the .vagrant directory separately on each of your machine (a folder that is not shared) so each machine will create its own VM.
You can have the VAGRANT_CWD set in your bash profile for each computer if you plan to have a different location, but you can also have for example a workhere.sh script that will just do export VAGRANT_CWD=/folder... if you have the same settings on both computer and just do source workhere before you do vagrant up
the other option (I did not test) will involve a few steps: export/import the VM once created from VirtualBox into one computer to another. The issue here will be to keep Id. I am not sure but normally virtual box should keep the Id when you import into the other computer.
you can check the file under /Users/<user>/Library/VirtualBox/VirtualBox.xml and review the entry under <MachineRegistry>, you will get the uuid of the machine entry, make sure they match between your 2 computers after you export/import
for vagrant there is another file you need to sync between your 2 computer /Users/<user>/.vagrant.d/data/machine-index/index which list of available VM on the computer. If you have other VM on one computer not available on this other, it would be ok to sync but best is to copy only the necessary entry for the VM you want to sync.
After you've done this and you sync the .vagrant folder, you should be able to vagrant up from one computer or the other.
Again, I did not test all the steps but I assume this would work.
Few notes:
this will work only if the 2 computers have the same settings (same OS (if not version at least same family), folder structure as some files involve full path, same virtual box version ...)
vagrant box should be in sync on the 2 computers (but I assume this is the case as you can vagrant up from same Vagrantfile)
if you destroy/create the VM on any of the computer, you will need to sync again the Id as virtual box will assign a new Id each time you create a new VM
Vagrant provides an environment variable for exactly this use case: VAGRANT_DOTFILE_PATH
See the documentation here:
https://www.vagrantup.com/docs/other/environmental-variables.html#vagrant_dotfile_path
VAGRANT_DOTFILE_PATH
VAGRANT_DOTFILE_PATH can be set to change the directory where Vagrant stores VM-specific state, such as the VirtualBox VM UUID. By default, this is set to .vagrant. If you keep your Vagrantfile in a Dropbox folder in order to share the folder between your desktop and laptop (for example), Vagrant will overwrite the files in this directory with the details of the VM on the most recently-used host. To avoid this, you could set VAGRANT_DOTFILE_PATH to .vagrant-laptop and .vagrant-desktop on the respective machines. (Remember to update your .gitignore!)
I have created a puppet/vagrant/VirtualBox generated installation of Ubuntu running on a Windows host; see https://bitbucket.org/dmenne/rstudio-shiny-server-on-ubuntu for details. This allows users to run RStudio and Shiny server on Windows. In Vagrantfile, I have
config.vm.synced_folder "shiny-server", "/srv/shiny-server", create:true
to create a shared folder. When I start the VM with vagrant up or vagrant reload, everything works ok.
One customer does not want to install vagrant etc, and asks for a standalone VM to be started/stopped with the VirtualBox Manager on Windows. However, after I shutdown a vagrant-booted VM Box, my synced folders do not connect/mount again on VM restart, even if they turn up correctly in the shared folders dialog of the VirtualBox Manager.
How can I shrink-wrap a Vagrant-generated VM so it can be started/stopped without Vagrant?
EDIT March 2015:
I still could not resolve this. When I force automount, on restore media/sf_<folder> is synced, not the required folder. How can I force VirtualBox to use sync-template from Vagrantfile after a restart?
And how do I force automount in vagrant without doing it manually.
After some further debugging and the lack of response to a similar query on the google/vagrant forum:
When you use synced folders in puppet, you must restart VirtualBox with vagrant up or vagrant reload
If you use the VirtualBox GUI to stop/restart, automount restores the synced folders incorrectly, i.e. to /media/sf_; this cannot be corrected without using a vagrant reload,
The only alternative without vagrant is to save the state in VirtualBox (CTRL-V). After a restart, the synced folders are restored correctly. However, it is probably impossible to force end-users to always manually save the state.
To use persistent synced folders, you must use upstart or similar methods; it cannot be done with Vagrantfile only.
See also Alvaro's response:
https://groups.google.com/forum/#!topic/vagrant-up/oBU0kqPLzYk
There are two parts to getting this to work. First, we need to get the synced folders automatically mounting from the host, which is the case of a Linux guest is a bit of a misnomer, because it's more "being automatically made available for mounting", or "automatically shared". For each shared folder (gemainsame ordner) you must turn on auto mount (automatische einbinden)
To do this, click on the edit shared folder icon for each share
And check auto mount (automatische einbinden)
At the end you should see "Ja" under "automatische Einbinden" for all the shares to should auto-sync
If the guest system is Ubuntu (or any Linux system), then having done this, all the synced folders should now be visible within to the guest, but the guest won't automatically mount them. You will need to put an entry into your /etc/fstab for each folder you want automatically mounted in the guest.
Since you are using VirtualBox, Vagrant will presumably choose to implement the synced folders using VirutalBox's shared folder provisioning method. To the guest system in Linux, depending on your version of Guest Additions, this looks like either an smb/cifs share with the name (by default) of //vboxsrv/, or a file system of type "vboxsf".
The vboxsf is from more recent version of guest additions (4.1.18 onwards at least), and automount option 'just works'. On booting a Linux guest VM with an automount set share called 'bob', the system should mount Bob automatically (without an fstab entry) at /media/sf_Bob. The full output of the relevant line from mount is
none on media/sf_Bob type vboxsf (rw,nodev,relatime)
If this isn't working, check that you can see a samba network share from within your guest system, using smbclient or smbtree. It should look like //vboxsrv/Bob. In your fstab then, you would add a line like this
#share name #mount point in guest #fstype #options #dump/pass
//vboxsrv/Bob /mnt/Bob cifs auto,rw 0 0
You may wish to read the manual page for mount.cifs to tune the options for each mount, especially with regards to file ownership and permissions (relevant options to investigate are forceuid, uid, forcegid, gid, file_mode, and dir_mode)