I've the problem that my home directory is actually located on a remote server and with ~/.vagrant.d sitting on that server, the performance of vagrant decreases heavily (and file-server backup size increases).
So is there any way to move at least ~/vagrant.d/boxes out of the home directory?
Cheers.
By default Vagrant uses ~/.vagrant.d. Fortunately, vagrant provides an environment variable called VAGRANT_HOME by which you can set vagrant home.
Just do the following to change the vagrant home (this only works in the current session)
export VAGRANT_HOME=/path/to/vagrant
To make it permanent, add this to your ~/.bash_profile (for login shell).
Update: VAGRANT_HOME has been added to the documentation - Environmental Variables
VAGRANT_HOME can be set to change the directory where Vagrant stores global state. By default, this is set to ~/.vagrant.d. The Vagrant home directory is where things such as boxes are stored, so it can actually become quite large on disk.
VAGRANT_HOME does not work well in my Windows 8.1. It worked for me when I changed the file
D:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.5.3\lib\vagrant\environment.rb
on line 117 to
#home_path = Util::Platform.fs_real_path("D:/vagrant/home/")
like Steve H said and it works fine.
It might be useful to permanently set this on a Windows box by executing
setx VAGRANT_HOME "/d/.vagrant.d/"
On Windows change line 17 of environment.rb located at:
vagrant\embedded\gems\gems\vagrant-1.x.x.dev\lib\vagrant\environment.rb
an other place (the root place where it read ENV variables) is in shared_helpers.rb, line 71 (vagrant v 1.6.5) :
# This returns the path to the ~/.vagrant.d folder where Vagrant's
# per-user state is stored.
#
# #return [Pathname]
def self.user_data_path
# Use user spcified env var if available
path = ENV["VAGRANT_HOME"]
# On Windows, we default to the USERPROFILE directory if it
# is available. This is more compatible with Cygwin and sharing
# the home directory across shells.
if !path && ENV["USERPROFILE"]
path = "#{ENV["USERPROFILE"]}/.vagrant.d"
end
# Fallback to the default
path ||= "~/.vagrant.d"
Pathname.new(path).expand_path
end
Anyway, I think the best way is to use the environment variable VAGRANT_HOME, in case of vagrant version upgrade.
You can use this function like:
disk_path = self.user_data_path().to_s
For Windows users, set the environment variable VAGRANT_HOME to the new location. You might need to restart your PC for it to take effect.
It works for me on Linux creating a simbolic link from a folder on my secundary hard drive to ~/.vagrant.d/boxes/.
Set of VAGRANT_DOTFILE_PATH environmental variable helped me on Windows machine. VAGRANT_HOME didn't work out.
Related
I must put all the files GO creates inside the structure of GO, not scattered. While changing GOPATH and GOROOT, I noticed the build folder on ~/.cache/go-build.
This SO thread didn't help at all, not either the article it links. It doesn't seems to deal directly with that. How can I change it?
Edit: the problem isn't how to find the GOCACHE, which I already know that can be viewed by go env GOCACHE, but how can I change that folder.
I've tried to add to ~/ .bashrc:
export GOCACHE=$HOME/path/to/folder, and now when I use go env GOCACHE, it points to the new folder but still tries to send files to ~/.cache/go-build. The log file is now returning the following error:
go: disabling cache (/home/<me>/.cache/go-build) due to initialization failure: mkdir /home/<me>/.cache/go-build: permission denied
The error shown
go: disabling cache (/home/<me>/.cache/go-build) due to initialization failure: mkdir /home/<me>/.cache/go-build: permission denied
Is because the directory /home/<me>/.cache/go-build does not exist and permissions to create a new directory aren't there. This shouldn't happen, it seems like some unknown factor in your build process is clobbering the GOCACHE settings
Do you literally have a user called <me>? That's quite unusual and ill advised, as <> are shell meta characters
As for setting the path, see https://github.com/golang/go/blob/master/src/cmd/go/internal/cache/default.go
and https://golang.org/pkg/os/#UserCacheDir
If GOCACHE env variable is set then it uses that. If not it uses os.UserCacheDir which is usually $HOME/.cache but can be overridden, see the docs
The simple answer is to set the GOCACHE env variable to be inside your Go containment area
Just to clarify. Go compiler and tools run inside another environment.
This other environment has variables set inside it, which Go will honour
On Linux systems, this environment is usually the bash shell. In the bash shell to set the GOPATH the command "export GOPATH=$HOME/go" is often used, to set up a GOPATH to a folder called go in the home directory of the current user. To set the GOCACHE set the variable in the environment you are using and Go will pick it up
cd $HOME
sudo chown -R <yourname>.<yourname> .cache/go-build
It works for me.
I was having the same issue, using a Mac.
I solved it by unlocking the folder, see prints below
The first one is a sign in Finder showing the folder is locked
And the second is where to unlock folder
I am running this command under windows 7:
git status
Now I am getting this error:
fatal: unable to access 'H:\/.config/git/config
I am disconnected from the network at the moment. Can I still fix this by changing the config location or creating a new config?
Can I still fix this by changing the config location or creating a new config?
You can simply change your environment variable HOME, in order to reference an existing local folder
set HOME=C:\local\path
In that folder, a .gitconfig can be defined in order to have a global git config file.
The msysgit/msysgit/git-cmd.bat defines it by default to:
#if not exist "%HOME%" #set HOME=%USERPROFILE%
Git will respect the HOME environment variable to determine the location of the global .gitconfig.
If asking your domain admin to reset your HOMEDRIVE and HOMEPATH variable back to your local user profile is not an option, you can simply change the HOME variable instead (which is usually unset, so there won’t be a conflict) at the top of your shell to make Git use that location.
For example, if you’re using Git Bash, you can simply add the following line to the bottom of your shell profile, located at C:\Program Files (x86)\Git\etc\profile:
export HOME="$USERPROFILE"
(I think $USERPROFILE is still left to the default even if the domain settings change your home drive. Of course, you can always specify a fixed path if that doesn’t work)
If you are using other shells, you can do similar things, for example in PowerShell:
$env:HOME = $env:USERPROFILE # or = 'C:\Users\poke\'
Of course, since the variable is unset by default, you could also set it at Windows level in your system configuration. That way, every program would use it automatically.
Afterwards, all Git commands will automatically look at $HOME\.gitconfig.
You need to specify the config file location using git config and the -f option.
git config -f your_config_file
Im trying to start up Homestead 2.0 for a Laravel app however every time I run
homestead up
I get the output
/Applications/Vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/shared_helpers.rb:89:in `expand_path': couldn't find HOME environment -- expanding `~' (ArgumentError)
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/shared_helpers.rb:89:in `expand_path'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/shared_helpers.rb:89:in `user_data_path'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/plugin/manager.rb:16:in `user_plugins_file'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/plugin/manager.rb:27:in `instance'
from /Applications/Vagrant/bin/../embedded/gems/gems/vagrant-1.6.5/lib/vagrant/pre-rubygems.rb:22:in `<main>'
What does couldn't find HOME environment -- expanding~' mean and how can I fix it? I'm using Oh-my-zsh as a shell.
Search your php.ini with this commands: php --ini
In your php.ini file, set variables_order = "EGPCS".
Thats it.
I'm having the same issue. As a work-around, you can add
ENV["HOME"] = "/Users/your-user-name"
to the file
/Applications/Vagrant/embedded/gems/gems/vagrant-*version*/lib/vagrant/shared_helpers.rb
right underneath require "tempfile" to get it up and running
You have to specify HOME environmental variable for your shell. Now your home dir is being found by checking ~ which always returns your default home dir i.e. cd ~ takes you to home dir.
The '~' shortcut in shell stands for the home folder for a user. For example, on OSX, if the user name is gael, the ~ is expanded (replaced) by the path which is /Users/gael.
For the second part of your question, may try to set HOME before launching it :
export HOME=/Users/gael
Regarding the answers by #michal.z & #gael
I had this problem and I am able to successfully
echo $HOME
which returns
/home/my-username
but I still got the error :-/
Anyway. I chose to follow #Adunahay s advice and I manually added the environment variable to the shared_helpers.rb file.
I have tortoiseSVN installed alongside subversion for windows (not using TortoiseSVN command client tools because of restrictive purposes).
I have a batch file that runs an svn update on certain folders which are used as environmental variables in Windows. Is it possible to svn update a folder using just the folder name?
e.g. from this:
cd C:\foo\johnsmith\testing\
svn update
to something like this?
cd testing\
svn update
I should add that environmental variables are new to me...
With regards to Alrocs comment, the path C:\foo\johnsmith\testing\ is in the system environmental variable "Path".
You can't cd to directory, which is part of your $PATH$. But you can use environment variable, which explicitly contain needed path only (after all - variable is just string)
c:\TEMP>echo "%USERPROFILE%"
"C:\Documents and Settings\Badger"
c:\TEMP>cd "%USERPROFILE%"
C:\Documents and Settings\Badger>
Never assume anything about environment variables that you haven't set via your batch file. Just because it's there today/on your computer doesn't necessarily mean it'll be there tomorrow or on another computer.
But you aren't using an environment variable in your script in the first place.
If you need to update a specific path, be explicit and update that path by specifying the whole path. Don't assume that your testing directory will be an immediate child of the directory you're running the batch file in unless you can control everything else - the whole subdirectory structure, where the batch file executes from, and how it executes.
I use cwRsync to sync up some file from Windows to Ubuntu. This process used to work fine on Vista, but since I upgraded to Windows7, I keep getting permission issues.
Some background... I did use to get the same permission issues on Vista, but that was resolved by using the CYGWIN=nontsec environment variable.
The premission problem
rsync: failed to modify permissions on xxx: Permission denied (13)
Since windows and UNIX file permissions differ, sync'ing files with windows permissions doesn't make sense. What rsync does is set the permission on the UNIX side to 0 (d---------). To prevent this, cygwin has the nontsec variable which instructs it to ignore the windows file permissions.
The problem is, on Windows7, nontsec appears not to have any effect.
re your solution, I had to make an adjustment to see it work for me - instead of your etc/fstab content, I used this content from the forum topic you reference:
none /cygdrive cygdrive binary,posix=0,user,noacl 0 0
I'm using cwRsync installer 4.0.3. I'm happy enough that it works for me but I can't offer a reason why, not being familiar enough with fstab syntax and options. Hopefully it adds something useful to someone else.
I figured out that it wasn't Windows 7 that was causing the issue. Rather, it was the new version of cwrsync that was ignoring the nontsec environment var. For cwRsync versions higher than 1.7, you need to use the noacl option. (see forum topic: No access to subfolders of RSYNC backup folder)
The solution involves creating an fstab file with the noacl option:
# In this example, my cwRsync dir is located at: "C:/Program Files (x86)/cwRsync"
# Filename: "C:/Program Files (x86)/cwRsync/etc/fstab"
C:/Program\040Files\040(x86)/cwRsync / ntfs override,binary,noacl 0 0
C:/Program\040Files\040(x86)/cwRsync/bin /usr/bin ntfs override,binary,noacl 0 0
And that's it! You can also remove the CYGWIN=nontsec env var since it's no longer used.
I was having this same problem copying from my Solaris based webhost down to my local PC. The PC permissions were wacked when the files were copied down. I setup the fstab file but no go.
In the end I realized that I was making a full path call to rsync.exe which meant my current directory was no picking up the etc folder I just created. To resolve this, I added these lines just above the call to the rsync command and it worked perfectly.
SET CWRSYNCHOME=%PROGRAMFILES%\CWRSYNC
c:
cd %CWRSYNCHOME%
Now my file permissions are correctly defaulting to the parent folder permissions without issues.
I just wanted to tag this onto this thread in case anyone else in the future is coming across the same issue I was.
This is now also addressed in the cwrsync FAQ:
http://www.itefix.no/i2/node/11324
I can also report the fix in the FAQ (and Raise's answer) worked for me as well.
I had the same problem, but none of the solutions worked for me, until I realized my destination folder was outside the rsync folder. (I wanted to rsync files from Linux to Windows.)
Here is what worked for me:
Create a subdir etc inside the cwRsync folder (that is, where the rsync.exe resides).
Create a file named fstab (no suffix) inside that folder.
Insert one line into that fstab file, be sure to have UNIX line endings!
none /cygdrive cygdrive binary,posix=0,user,noacl 0 0
Set environment:
SET CWRSYNCHOME=<cwRsync installation path>
SET HOME=<Directory to save user configuration files, like ssh known_hosts>
Before starting rsync.exe (this was the most important step in my case):
cd <Destination folder>
The SET HOME part is important for SSH, it will create a .ssh subfolder there with a known_hosts file.