How to fix vagrant up error related to NFS issue? - nfs

I ran into a very strange issue this morning. When I rebooted my machine, and tried to run vagrant up, I get this error;
==> default: Mounting NFS shared folders...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mount -o vers=3,rw,tcp,nolock,noacl,async 10.0.1.1:/Users/me/code /vagrant
Stdout from the command:
Stderr from the command:
mount.nfs: requested NFS version or transport protocol is not supported
I didn't change any configuration settings, or update my machine or anything. Of things I know, nothing has changed. What gives? Anyone have any ideas as to what the issue is and what I can do to fix it?

For anyone that runs into this same issue and none of the other solutions you find seem to work, my issue was 127.0.0.1 localhost missing from my /etc/hosts file. Not sure how or why it went missing, but when adding this back, it fixed the issue.

Related

why ssh connection timed out in vscode?

I installed git instead of openssl to use Remote-SSH in VSCode.However,after I completed the config document and tried to connect to the remote host.I failed. The error info is showed in the below pic.error info
error info:
[11:27:12.631] remote-ssh#0.48.0
[11:27:12.632] win32 x64
[11:27:12.656] SSH Resolver called for "ssh-remote+23321", attempt 1
[11:27:12.659] SSH Resolver called for host: 23321
[11:27:12.659] Setting up SSH remote "23321"
[11:27:12.790] Using commit id "26076a4de974ead31f97692a0d32f90d735645c0" and quality "stable" for server
[11:27:12.798] Testing ssh with ssh -V
[11:27:13.099] ssh exited with code: 0
[11:27:13.100] Got stderr from ssh: OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
[11:27:13.128] Running script with connection command: ssh -T -D 49485 23321 bash
[11:27:13.132] Install and start server if needed
[11:27:13.151] Terminal shell path: C:\Windows\System32\cmd.exe
[11:27:30.151] Resolver error: Connecting with SSH timed out
[11:27:30.178] ------
I had the same problem but the above solutions didn't work with my setup,
but the following setting did work:
"remote.SSH.useLocalServer": false
I got this solution from github reported issues and fix
In my case, the problem was caused by a too long authentication process on the server-side.
Solved it by extending the Connect Timeout from 15 to 30 seconds.
Instructions:
open your vscode Command Palette (via keyboard shortcut or from the
View menu).
search for the Remote-SSH: Settings.
scroll till you find the Connect Timeout.
change it to a longer duration than 15 secs.
key F1
Remote-SSH: Settings
Connect Timeout: from 15 seconds to 60 seconds solve my connection issue
You can try the following approaches:
ssh to your remote server. Then run the following commands to clean data folder and bin folder under .vscode-server folder on the server:
cd ~/.vscode-server
rm data/* -rf
rm bin/* -rf
If step 1 does not work, ssh to your remote server and delete the entire .vscode-server folder with the following command:
rm -rf ~/.vscode-server
Please note that this will also remove the extensions that you installed on the server.
Downgrade the version of the remote-SSH extension in vscode. Look up the extension in the vscode interface, right click on that, and you will find the option "Install Another Version ...". Install the previous version of the current one. If it does not work keep downgrading the version.
I had the same problem before, I solved this by deleting "terminal.integrated.inheritEnv": false inside ~/.config/Code/User/setting.json
I found the solution here in this thread from user oreilm49:
https://github.com/microsoft/vscode-remote-release/issues/1137
in vscode settings :
search conpty and uncheck it
I had same issue, my problem was solved after changing settings in the json file:
I removed "terminal.integrated.inheritEnv": false inside ~/.config/Code/User/setting.json
I added "remote.SSH.useLocalServer": true inside ~/.config/Code/User/setting.json
It worked for me after so many different trials
This might be a very foolish solution but it actually works for me, so I will write it down in case any other people get into the same problem.
I made modifications to the config file for SSH, then all the trials for connection ran into the error of 'Connecting SSH timed out'. I tried many possible solutions but none of them solved my problem.
Then I just closed the VScode and restarted it. Then everything works.
I had a case of this. I my client (local computer) is a Mac, and I was connecting to Linux host. I just went to the setting "Remote Platform" under Remote.SSH settings, and explicitly told it that I am connecting to a Linux remote. After this, it started to work.
I had this issue because of version missmatch of client and server. After updating both to the same version, it worked for me.
The issue with me was timeout at first. I tried increasing the timeout in settings but then later found the issue was with "tar".
The vscode-server.tar.gz (probably a little change in the file name) was not able to install due to tar not being present in my host.
So I installed tar in the host as "yum install tar"
And then tried reconnecting to the server and it worked

Vagrant GuestAdditions issue

Host OS: Windows 10
Vagrant: 2.2.4
VirtualBox: 6.0.6 r130049
When I run vagrant up, it prints this error message:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
setup
Stdout from the command:
Stderr from the command:
bash: line 4: setup: command not found
The machine can be booted normally and SSH from my host to Virtual machine is OK but the synced folder is not working. I know this may not be a critical issue but still feel frustrated as I use my host machine to develop codes and "sync" these codes so that they can be loaded in my virtual machine.
Any advice is highly appreciated.
ps: When I boot a full UI virtual machine (different from my above mentioned) from my VirtualBox directly, it seems OK to have a "sync" directory and the VBGuestAdditions can be installed without errors.
It is a bug in VirtualBox 6.0.6 and it still exists in 6.0.8. The solution is to downgrade your VirtualBox itself and the Guest Extensions to 6.0.4.

vagrant ssh uses wrong ssh executable

I have a vagrant box with CentOS7 running under KVM/QEMU (libvirt) on my Fedora 29 host. vagrant up works fine. vagrant ssh fails with:
/usr/share/vagrant/gems/gems/vagrant-2.1.2/lib/vagrant/util/safe_exec.rb:39:
in `exec': : Permission denied - /home/username/bin/sshPermission denied - /home/username/bin/ssh ( (Errno::EACCESErrno::EACCES)
The doc says: Vagrant will attempt to use the local SSH client installed on the host machine. However, which ssh correctly results in: /usr/bin/ssh. So why vagrant doesn't use it ?
The directory! /home/username/bin/ssh was included in the PATH env when the box was created and vagrant seems to have stored this information somewhere. Removing the directory from PATH didn't help. Only when I rename or remove the directory vagrant ssh does work.
Can anyone tell me where vagrant stored the wrong info ?
Edit: The Vagrantfile is nearly empty, only config.vm.box contained...
Guess I found the reason - seems to be a bug or strange behavior of the vagrant version 2.1.2 that I use:
I still had directory /home/username/bin in the PATH env. Vagrant seems to list all entries in all directories included in PATH to look for ssh and finds subdirectory /home/username/bin/ssh not realizing that this is a directory ...
After removing /home/username/bin the command vagrant ssh works as expected. So unless vagrant is improved I have to permanently rename my /home/username/bin/ssh directory ...

Docker Centos 7 image running Apache2 "DocumentRoot ... is not readable"

I have a docker container running a Centos 7 image. All it needs to do is run a simple Apache2 server. When the container starts it exits immediately with:
AH00526: Syntax error on line 119 of /etc/httpd/conf/httpd.conf:
DocumentRoot '/var/www/html' is not a directory, or is not readable
I did some basic checks:
Folder exists
Permissions are ```rwx r_x r_x root root```` for each folder /var/www/html
Tried chown -R apache /var/www (no straw shall remain unclutched!)
SELinux is disabled (... or is it?)
When I enter the container with a bash entry point, I can then start apache as root with /sbin/httpd -D FOREGROUND and everything works as expected.
So I think its almost certainly a permissions thing. Googling found many pages with my error e.g.
Apache restart causes DocumentRoot must be a directory, even though it is a directory and there seem to be no privilege issues
This particular page closely describes what I am getting and the solution in almost every page is configure SELinux. However SELinux is disabled. Even in that link there is comment from the OP
My version of linux isn't Security Enhanced Linux, so without understanding I tried it anyway: no effect.
Yet they accepted the solution which was configure SELinux.
I think I am missing something, almost certainly SELinux related, but I can't figure it out. The docker image has the following (distinct lack of) SELinux settings:
/etc/selinux contains only semanage.conf and tmp/ (empty)
/usr/sbin contains no se* executables
rpm -qa | grep selinux
libselinux-2.5-12.el7.x86_64
/etc/sysconfig/selinux does not exist
So in the Dockerfile I tried RUN echo "SELINUX=disabled" > /etc/sysconfig/selinux
doing yum install -y policycoreutils installs sestatus in /usr/sbin. Running sestatus gives
SELinux status: disabled
With or without /etc/sysconfig/selinux
It really looks like SELinux is disabled, yet the error looks so much like it is enabled.
The issue in this case was due to the way the container was launched.
I use docker-compose to launch this particular container but the paths for the volume mapping were incorrect.
I am still not sure why this causes apache to fail to start in the way it does but correcting the paths fixed the issue.

NFS mount command stuck without any error

NFS server: i added a path in /etc/exports
[local-path] [client-ip] (rw,sync,no_root_squash,no_subtree_check)
run $exportfs -a
Succeeds!
NFS client:
Now run: $mount [server-ip]:[path] [local-path]
Now the mount command just gets stuck there, no error, no cli o/p.
How to even get what's the error?
This problem go sorted out by restarting the computer. I think nfs daemon restart should also work.