Valet: VALET_HOME_PATH is set to /var/root/.valet

[arandilopez]

I have seen in issues and post around that valet creates a .valet/ directory un user's home directory. In my case my valet installation doesn't create that file.

The VALET_HOME_PATH constant is set to posix_getpwuid(fileowner(__FILE__))['dir'].'/.valet' is returning, in my case is: /var/root/.valet. This causes an error when nginx tries to set the error.log in valet.conf

I just ran valet install without sudo

Sorry for my bad english.

[zhse]

Same problem.
I may be wrong but seems like this part of the bash script:

if [[ "$EUID" -ne 0 ]]
then
    sudo $SOURCE "$@"
    exit
fi

causes php run as root during valet install process. Than VALET_HOME_PATH is defined during autoload process in helpers.php file:
define('VALET_HOME_PATH', $_SERVER['HOME'].'/.valet');
is set to /var/root/.valet
sudo php -r 'echo $_SERVER["HOME"]."\n"; -> /var/root
Finaly I get 'Bad gateway', because socket file is in the root folder.

Not running as root causes some permission denied warnings during install and leads to ping absence on *.dev hosts

[joshmanders]

Are you running this on macOS or Linux?

[arandilopez]

Me? on Mac OS

[zhse]

mac os sierra

[zhse]

Solution:

1. Stop and uninstall services

sudo brew services stop php71 dnsmasq nginx
brew uninstall php71 dnsmasq nginx

1. Remove related config files and valet home folder

sudo rm -r /usr/local/etc/php /usr/local/etc/nginx /usr/local/etc/dnsmasq.conf
sudo rm -r ~/.valet /var/root/.valet

1. Install services
   brew install php71 dnsmasq nginx
2. Hardcode your home path into valet source
   Modify 2 files: helpers.php and DnsMasq.php. Change $_SERVER['HOME'] to '/Users/user'
3. Install valet and don't forget to park
   valet install

[kasparasg]

I seem to be having the same issue as described by @arandilopez

[matrunchyk]

Same for me. @zhse's suggestions have fixed the issue. @mattstauffer why does $_SERVER['HOME'] resolve to /var/root ?

P.S. I was trying to fix it a recommended way by removing all config files and reinstalling everything from scratch. It didn't help. I ended up having /var/root/.valet folder which I believe is the reason why the other issue appears: valet secure doesn't create certificates, only config file which fails a whole nginx of course (see https://github.com/laravel/valet/issues/301 and https://github.com/laravel/valet/issues/521)

[drbyte]

I can't recreate this issue.
@matrunchyk @kasparasg @arandilopez @zhse Is this still an issue?

[matrunchyk]

Works for me now.

[stuartro]

I've run into the exact same issue—that is, /var/root/.valet folder. Uninstalled everything and about to reinstall as per instructions above, but can't find the 2 files: helpers.php and DnsMasq.php. Will search around for them, but might be worth someone looking into / documenting.

[stuartro]

I should mention that Valet install worked fine on High Sierra, but fails (with the /var/root/.valet issue) on Mojave - 10.14.3)

[stuartro]

If someone else runs into this, the files to edit are located in ~/.composer/vendor/laravel/valet/cli/includes/helpers.php and ~/.composer/vendor/laravel/valet/cli/Valet/DnsMasq.php.

In helpers.php, changed both lines 13 and 17 define('VALET_HOME_PATH', ... and define('VALET_LEGACY_HOME_PATH', ...) and in DnsMasq.php changed line 148.

[drbyte]

@stuartro I've tried a bunch of things but still can't make Valet do an install into /var/root/.valet ... (unless maybe of course I'm actually logged in "as root" ... which is highly unconventional (even impossible without getting creative), but I'm not doing that).

Installing the current version of Valet (right now, 2.2.1) on a fresh Mojave 10.14.3 when logged in as a user (with "Administrative rights") works fine: that is, it properly installs Composer into ~/.composer and Valet configs into ~/.config/valet.

Can you help me figure out how to make it do it incorrectly? How do I have to alter Mojave or PHP to make it do it wrong?

[Patistar]

I've tried a bunch of things as well with Mojave but can't make Valet do an install into ~/.valet.

A [example] symbolic link has been created in [/var/root/.config/valet/Sites/example].

Tried to pre-install php7.3, nginx and dnsmasq with brew, then removed them all and let valet do the install. When I run php -i the $_SERVER['HOME'] is always correct, only when running it with sudo php -i it points to /var/root/.
The version is 2.2.1 and which valet points to /Users/Patrick/.composer/vendor/bin/valet.
which php returns /usr/local/bin/php with php -v being PHP 7.3.3 (cli) (built: Mar 8 2019 16:40:07) ( NTS ).
I have no clue what else I can do except of manual setting the paths. Are you also installing it according to this guide: https://laravel.com/docs/5.8/valet#installation?

[Patistar]

Even though I got it perfectly working with @zhse solution and @stuartro references to the files, I had another look at it as I'm not a big fan of workarounds.

As already mentioned by @zhse, in the valet bash script the following lines can be found:

if [[ "$EUID" -ne 0 ]]
then
    sudo "$SOURCE" "$@"
    exit
fi

This makes sure the script is always run as root. As soon as I run php as root, the $_SERVER['HOME'] will be /var/root/ instead of /Users/Patrick/ (sudo php -i will display that).

Therefore there are only three options I can imagine why it is working for you:

1. Your $_SERVER['HOME'] does not change when php is run as root
2. Your valet script does not ask for your root password when it is executed
3. You did not unlock the root user (do you still need to unlock it?) and therefore you have a different behavior.

[mattstauffer]

OK, here's a fun test.

@zhse said when they ran this command:

sudo php -r 'echo $_SERVER["HOME"];'

the output was /var/root.

Not mine:

@patistar how about you?

[Patistar]

Mine is /var/root as well.

[drbyte]

@Patistar have you done anything to your PHP configs beyond just having Homebrew install PHP?
I'm puzzled about why my fresh Mojave install with a fresh Homebrew install and fresh PHP/Nginx/Valet install returns the current OSX user in both sudo and non-sudo ... but yours doesn't.
My OSX user in System Preferences is marked as "Allowed to administer this computer", but has nothing else special about it.

~ chris$ > php -i | grep HOME
HOME => /Users/chris
$_SERVER['HOME'] => /Users/chris

~ chris$ > sudo php -i | grep HOME
Password:
HOME => /Users/chris
$_SERVER['HOME'] => /Users/chris

Have you made php.ini changes of some sort? Reconfigured FPM with different user details? Changed permissions on files/folders beyond what Homebrew does by default?
Are there any system customizations made?
Other software tools installed that would alter PHP defaults?

I'm looking for a common thread that you and others getting 'root' instead of 'current user' may have done to your machines to cause this ... because it's the lack of that information that's leaving this issue unresolved for all of you.

[Patistar]

@drbyte It's a fresh php 7.3.4 installation (brew install php). I didn't change anything at the config after installation.
My system is not a fresh Mojave, but a Late 2013 Macbook Pro where I just constantly upgraded the operating system (not sure where I started).
My user is also marked as "Allowed to administer this computer" and I can't uncheck it, as it's my only user. In the Directory Utility.app the root is not activated (Edit > Enable Root User does not show "Disable Root User").

> which php
/usr/local/bin/php

> ls -la /usr/local/bin/php
lrwxr-xr-x  1 Patrick  admin  27 14 Apr 15:19 /usr/local/bin/php -> ../Cellar/php/7.3.4/bin/php

And the following php.ini is used (with and without sudo):

> php -i | grep ini
Configuration File (php.ini) Path => /usr/local/etc/php/7.3
Loaded Configuration File => /usr/local/etc/php/7.3/php.ini

The only other tool that uses a local php might be MAMPP which I have installed but haven't used for quite a while and it uses its own php versions and configuration within its directory.

A question: If you type sudo su and then cd ~ what will pwd tell you?

[drbyte]

sudo output:

chris# >php -r 'echo $_SERVER["HOME"];'
/Users/chris
chris# >sudo php -r 'echo $_SERVER["HOME"];'
/Users/chris
chris$ >sudo su
Password:
sh-3.2# pwd
/Users/chris
sh-3.2# cd ~
sh-3.2# pwd
/var/root
sh-3.2# php -r 'echo $_SERVER["HOME"];'
/var/root

[Patistar]

Ok, the issue seems to be caused by a different behavior of sudo on our machines. I can keep my environment variables if I use sudo -E or sudo --preserve-env.

> sudo -E php -r 'echo $_SERVER["HOME"];'
/Users/Patrick

Here are some information about my sudo "configuration":

> which sudo
/usr/bin/sudo

> ls -la /usr/bin/sudo
-r-s--x--x  1 root  wheel  370720 21 Mär 07:09 /usr/bin/sudo

> sudo --version
Sudo version 1.8.17p1
Sudoers policy plugin version 1.8.17p1
Sudoers file grammar version 45
Sudoers I/O plugin version 1.8.17p1

> sudo cat /etc/sudoers
# User privilege specification
root    ALL=(ALL) ALL
%admin  ALL=(ALL) ALL

And a bit more details (click on the arrow):

```.

sudo su
Password:
sh-3.2# sudo -V
Sudo version 1.8.17p1
Configure options: --with-password-timeout=0 --disable-setreuid --with-env-editor --with-pam --with-libraries=bsm --with-noexec=no --sysconfdir=/private/etc --without-lecture --enable-static-sudoers --with-rundir=/var/db/sudo
Sudoers policy plugin version 1.8.17p1
Sudoers file grammar version 45

Sudoers path: /etc/sudoers
Authentication methods: 'pam'
Syslog facility if syslog is being used for logging: authpriv
Syslog priority to use when user authenticates successfully: notice
Syslog priority to use when user authenticates unsuccessfully: alert
Send mail if the user is not in sudoers
Use a separate timestamp for each user/tty combo
Lecture user the first time they run sudo
Require users to authenticate by default
Root may run sudo
Allow some information gathering to give useful error messages
Visudo will honor the EDITOR environment variable
Set the LOGNAME and USER environment variables
Length at which to wrap log file lines (0 for no wrap): 80
Authentication timestamp timeout: 5,0 minutes
Password prompt timeout: 0,0 minutes
Number of tries to enter a password: 3
Umask to use or 0777 to use user's: 022
Path to mail program: /usr/sbin/sendmail
Flags for mail program: -t
Address to send mail to: root
Subject line for mail messages: * SECURITY information for %h
Incorrect password message: Sorry, try again.
Path to lecture status dir: /var/db/sudo/lectured
Path to authentication timestamp dir: /var/db/sudo/ts
Default password prompt: Password:
Default user to run commands as: root
Path to the editor for use by visudo: /usr/bin/vi
When to require a password for 'list' pseudocommand: any
When to require a password for 'verify' pseudocommand: all
File descriptors >= 3 will be closed before executing a command
Reset the environment to a default set of variables
Environment variables to check for sanity:
TZ
TERM
LINGUAS
LC_
LANGUAGE
LANG
COLORTERM
Environment variables to remove:
__BASH_FUNC<*
BASH_FUNC_*
RUBYOPT
RUBYLIB
PYTHONUSERBASE
PYTHONINSPECT
PYTHONPATH
PYTHONHOME
TMPPREFIX
ZDOTDIR
READNULLCMD
NULLCMD
FPATH
PERL5DB
PERL5OPT
PERL5LIB
PERLLIB
PERLIO_DEBUG
JAVA_TOOL_OPTIONS
SHELLOPTS
BASHOPTS
GLOBIGNORE
PS4
BASH_ENV
ENV
TERMCAP
TERMPATH
TERMINFO_DIRS
TERMINFO
DYLD_*
_RLD*
LD_*
PATH_LOCALE
NLSPATH
HOSTALIASES
RES_OPTIONS
LOCALDOMAIN
CDPATH
IFS
Environment variables to preserve:
XAUTHORIZATION
XAUTHORITY
PS2
PS1
PATH
LS_COLORS
KRB5CCNAME
HOSTNAME
DISPLAY
COLORS
Locale to use while parsing sudoers: C
Compress I/O logs using zlib
Directory in which to store input/output logs: /var/log/sudo-io
File in which to store the input/output log: %{seq}
Add an entry to the utmp/utmpx file when allocating a pty
PAM service name to use
PAM service name to use for login shells
Attempt to establish PAM credentials for the target user
Create a new PAM session for the command to run in
Maximum I/O log sequence number: 0
Enable sudoers netgroup support
Check parent directories for writability when editing files with sudoedit
```

[drbyte]

@Patistar this is very useful!

Turns out it's because of the difference between the current default sudoers config vs the one you're using (presumably yours has been inherited from much older OSX default, or you've reset it to blank at some point).

Here's the default /etc/sudoers file content (since somewhere around Lion I think):
(Notice all the env_keep directives, including HOME)

#
# Sample /etc/sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.

##
# Override built-in defaults
##
Defaults    env_reset
Defaults    env_keep += "BLOCKSIZE"
Defaults    env_keep += "COLORFGBG COLORTERM"
Defaults    env_keep += "__CF_USER_TEXT_ENCODING"
Defaults    env_keep += "CHARSET LANG LANGUAGE LC_ALL LC_COLLATE LC_CTYPE"
Defaults    env_keep += "LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME"
Defaults    env_keep += "LINES COLUMNS"
Defaults    env_keep += "LSCOLORS"
Defaults    env_keep += "SSH_AUTH_SOCK"
Defaults    env_keep += "TZ"
Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"
Defaults    env_keep += "EDITOR VISUAL"
Defaults    env_keep += "HOME MAIL"

Defaults    lecture_file = "/etc/sudo_lecture"

##
# User alias specification
##
# User_Alias    FULLTIMERS = millert, mikef, dowdy

##
# Runas alias specification
##
# Runas_Alias   OP = root, operator

##
# Host alias specification
##
# Host_Alias    CUNETS = 128.138.0.0/255.255.0.0
# Host_Alias    CSNETS = 128.138.243.0, 128.138.204.0/24, 128.138.242.0
# Host_Alias    SERVERS = master, mail, www, ns
# Host_Alias    CDROM = orion, perseus, hercules

##
# Cmnd alias specification
##
# Cmnd_Alias    PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less

##
# User specification
##

# root and users in group wheel can run anything on any machine as any user
root        ALL = (ALL) ALL
%admin      ALL = (ALL) ALL

## Read drop-in files from /private/etc/sudoers.d
## (the '#' here does not indicate a comment)
#includedir /private/etc/sudoers.d

[drbyte]

From the research shared by various folks in this thread and especially @Patistar today, and a quick test, I believe the following will resolve this issue:

a. Ideally update one's /etc/sudoers file to the more modern defaults.

b. I've submitted PR #770 for the following:
Valet can be updated to preserve environment variables when it leaps into sudo mode by adding the --preserve-env flag @Patistar mentioned, as follows:

/valet file:

if [[ "$EUID" -ne 0 ]]
then
-    sudo "$SOURCE" "$@"
+    sudo --preserve-env "$SOURCE" "$@"
    exit
fi

[mattstauffer]

@drbyte's fix is merged into master. If anyone on this thread, especially @Patistar, knows how to test the dev-master branch of valet, could you check this out before I tag a release? Thanks!

[Patistar]

@mattstauffer Unfortunately I don't know how to test it. But if you can link me a guide, I will test it. Will it work according to this guide: https://gist.github.com/wimvds/7150868?

[drbyte]

@Patistar there are a few ways, depending on what you wish to test, and what state the change/PR is in.

Simplest is if you're just wanting to test a single change: just go edit the files directly in your project ... knowing they'll be wiped out when you do a composer update later (er, composer global update in this case, since valet is installed globally). The Valet files are stored in ~/.composer/vendor/laravel/valet

But, since this PR has been merged into master, you can also just tell your setup to use dev-master. Fastest way to do that is:

composer global require laravel/valet:"dev-master"

Then whenever you run composer global update it'll offer you to keep/discard/stash+merge your changes with whatever is coming in from master.
You can always go back to the latest "released" version by running composer global require laravel/valet

[Patistar]

@drbyte Thanks for your explanation! As I didn't wanted to destroy my nicely working configuration I tested it the following way.
Reset my /etc/sudoers file back to where the issues existed and called valet. This was the output:

> valet
Laravel Valet 2.3.0

Usage:
  command [options] [arguments]

Options:
  -h, --help            Display this help message
  -q, --quiet           Do not output any message
  -V, --version         Display this application version
      --ansi            Force ANSI output
      --no-ansi         Disable ANSI output
  -n, --no-interaction  Do not ask any interactive question
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Available commands:
  help     Displays help for a command
  install  Install the Valet services
  list     Lists commands

It told me valet is not installed, even though it is. Therefore: Issue on previous version with my old /etc/sudoers/ reproducable.

Then I run composer global require laravel/valet:"dev-master" and called valet again. This is the output:

> valet
Password:
Laravel Valet 2.3.0

Usage:
  command [options] [arguments]

Options:
  -h, --help            Display this help message
  -q, --quiet           Do not output any message
  -V, --version         Display this application version
      --ansi            Force ANSI output
      --no-ansi         Disable ANSI output
  -n, --no-interaction  Do not ask any interactive question
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Available commands:
  fetch-share-url    Get the URL to the current Ngrok tunnel
  forget             Remove the current working (or specified) directory from Valet's list of paths
  help               Displays help for a command
  install            Install the Valet services
  link               Link the current working directory to Valet
  links              Display all of the registered Valet links
  list               Lists commands
  log                Tail log file
  on-latest-version  Determine if this is the latest version of Valet
  open               Open the site for the current (or specified) directory in your browser
  park               Register the current working (or specified) directory with Valet
  paths              Get all of the paths registered with Valet
  restart            Restart the Valet services
  secure             Secure the given domain with a trusted TLS certificate
  share              Generate a publicly accessible URL for your project
  start              Start the Valet services
  stop               Stop the Valet services
  tld                [domain] Get or set the TLD used for Valet sites.
  trust              Add sudoers files for Brew and Valet to make Valet commands run without passwords
  uninstall          Uninstall the Valet services
  unlink             Remove the specified Valet link
  unsecure           Stop serving the given domain over HTTPS and remove the trusted TLS certificate
  use                Change the version of php used by valet
  which              Determine which Valet driver serves the current working directory

It found my existing installation in /Users/Patrick.

@mattstauffer Conclusion: The fix works! Thanks for the quick implementation!

[adamwathan]

Finally updated to a recent version of Valet and that --preserve-env flag gives me this error any time I run valet:

sudo: sorry, you are not allowed to preserve the environment

Means I have to do sudo valet ... for anything which kinda sucks. Removing that flag lets me do valet ... normally. Is there something else I need to change on my machine to make that work?

[drbyte]

I ran into this same issue yesterday.

While removing the --preserve-env from the script will bypass the message, I found another approach which I'm exploring with some degree of success. You might try this:

/cli/valet/Valet.php

    function createSudoersEntry()
    {
        $this->files->ensureDirExists('/etc/sudoers.d');

        $this->files->put('/etc/sudoers.d/valet', 'Cmnd_Alias VALET = /usr/local/bin/valet *
-%admin ALL=(root) NOPASSWD: VALET'.PHP_EOL);
+%admin ALL=(root) NOPASSWD:SETENV: VALET'.PHP_EOL);
    }

(keep the indentation as-is)

And then re-run valet trust so it resets the sudoers entry.

[drbyte]

@adamwathan I can confirm that the above tweak also works on 10.14.5

[adamwathan]

Nice that works perfect for me, thanks Chris!

[AmmarCodes]

If anyone has this issue again and he's already on the latest version of valet, you need to update this file:

sudo vim /etc/sudoers.d/valet

And change the last line to be:

%admin ALL=(root) NOPASSWD:SETENV: VALET

Credits to a previous comment.

[drbyte]

If anyone has this issue again and he's already on the latest version of valet, you need to update this file

... or delete the /etc/sudoers.d/valet file and re-run valet trust