I have a React app made using create-react-app. I've been running this app without any issues for a few months now but have recently ran into an issue with starting the app because it says the port is in use. Here is the error message: Something is already running on port 3000. I'm trying to run the app on a Windows 10 machine.
Everything I've tried so far is listed below:
Running netstat -an and checking the output. This shows nothing running on port 3000.
Running netstat -an | findstr "3000". This shows no output.
Running npx kill-port 3000. I still get the port in use error message after running this.
Changing port that the app is running on. It doesn't matter which port I choose, it always says the port is in use.
Checking the Listening Ports list in Resource Monitor shows nothing listening on port 3000
Restarting my PC
The only thing that works is running the app in a Ubuntu 20.04 VM... which seems to indicate there's something listening on port 3000 on my Windows machine. However, I'm not sure what else I can do to troubleshoot this issue. I'm looking for suggestions on what else I could try.
Edit
Here's the contents of my hosts file C:\Windows\System32\drivers\etc\hosts:
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
# Added by Docker Desktop
192.168.2.115 host.docker.internal
192.168.2.115 gateway.docker.internal
# To allow the same kube context to work on the host and the container:
127.0.0.1 kubernetes.docker.internal
# End of section
You can change it like below and try again, I'm not sure try once:
FYI, C:\Windows\System32\drivers\etc\hosts
Change to,
# localhost name resolution is handled within DNS itself.
127.0.0.1 localhost
::1 localhost
Instead of below this:
127.0.0.1 kubernetes.docker.internal
I resolved the issue by restarting the WinNAT service. I found the solution in the answers here: Error: listen EACCES: permission denied 0.0.0.0:3001
These are the steps:
Start Command Prompt or PowerShell as Administrator
Stop WinNAT with this command: net stop winnat
Start WinNAT again with this command: net start winnat
I am using an Azure DSVM in a DevTest Lab running Windows Server 2019. I am trying to get Docker installed and working to allow me to run local experiments from Azure ML Service environments.
I want to build a custom Linux container on Docker - which I believe is possible on Windows from reading some other online posts (I can't use a Linux host for various reasons). When I try to create such an image that contains a WORKDIR ... step, I get a "container ***** encountered an error during CreateProcess: failure in a Windows system call" error.
I installed Docker on the DSVM (which is a Standard D2s_v3) by adding the "Docker" artifact at creation and then running the following commands to enable Linux containers:
$> Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
$> [Environment]::SetEnvironmentVariable("LCOW_SUPPORTED", "1", "Machine")
Running a simple Linux container works fine:
$> docker run --rm -it alpine:latest
/ # ls
bin dev etc home lib media mnt opt proc root run sbin srv sys tmp usr var
/ #
To build a custom image, I'm using a simple Dockerfile as follows:
FROM alpine:latest
WORKDIR /abm
The image appears to build successfully:
$> docker build --no-cache -t abm-alpine:workdir -f .\abm-alpine.Dockerfile .
Sending build context to Docker daemon 2.048kB
Step 1/2 : FROM alpine:latest
---> a187dde48cd2
Step 2/2 : WORKDIR /abm
---> 495f8ecb3a0e
Removing intermediate container 219e91296e47
Successfully built 495f8ecb3a0e
Successfully tagged abm-alpine:workdir
When I run the image, I get the following error:
$> docker run --rm -it abm-alpine:workdir
C:\Program Files\Docker\docker.exe: Error response from daemon: container 01fad57c971d672d91238a6c6ec21376e033006ec4c26563e91e7288cfb3bfeb encountered an error during CreateProcess: failure in a Windows system call: The virtual machine or container exited unexpectedly. (0xc0370106) extra info: {"CommandArgs":["/bin/sh"],"WorkingDirectory":"/abm","Environment":{"HOSTNAME":"01fad57c971d","PATH":"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","TERM":"xterm"},"EmulateConsole":true,"CreateStdInPipe":true,"CreateStdOutPipe":true,"ConsoleSize":[50,120],"OCISpecification":{"ociVersion":"1.0.0","process":{"terminal":true,"consoleSize":{"height":50,"width":120},"user":{"uid":0,"gid":0},"args":["/bin/sh"],"env":["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","HOSTNAME=01fad57c971d","TERM=xterm"],"cwd":"/abm","capabilities":{"bounding":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"effective":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"inheritable":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"permitted":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"]}},"root":{"path":"rootfs"},"hostname":"01fad57c971d","mounts":[{"destination":"/proc","type":"proc","source":"proc","options":["nosuid","noexec","nodev"]},{"destination":"/dev","type":"tmpfs","source":"tmpfs","options":["nosuid","strictatime","mode=755","size=65536k"]},{"destination":"/dev/pts","type":"devpts","source":"devpts","options":["nosuid","noexec","newinstance","ptmxmode=0666","mode=0620","gid=5"]},{"destination":"/sys","type":"sysfs","source":"sysfs","options":["nosuid","noexec","nodev","ro"]},{"destination":"/sys/fs/cgroup","type":"cgroup","source":"cgroup","options":["ro","nosuid","noexec","nodev"]},{"destination":"/dev/mqueue","type":"mqueue","source":"mqueue","options":["nosuid","noexec","nodev"]},{"destination":"/dev/shm","type":"tmpfs","source":"shm","options":["nosuid","noexec","nodev","mode=1777"]}],"linux":{"resources":{"devices":[{"allow":false,"access":"rwm"},{"allow":true,"type":"c","major":1,"minor":5,"access":"rwm"},{"allow":true,"type":"c","major":1,"minor":3,"access":"rwm"},{"allow":true,"type":"c","major":1,"minor":9,"access":"rwm"},{"allow":true,"type":"c","major":1,"minor":8,"access":"rwm"},{"allow":true,"type":"c","major":5,"minor":0,"access":"rwm"},{"allow":true,"type":"c","major":5,"minor":1,"access":"rwm"},{"allow":false,"type":"c","major":10,"minor":229,"access":"rwm"}]},"namespaces":[{"type":"mount"},{"type":"network"},{"type":"uts"},{"type":"pid"},{"type":"ipc"}],"maskedPaths":["/proc/kcore","/proc/latency_stats","/proc/timer_list","/proc/timer_stats","/proc/sched_debug"],"readonlyPaths":["/proc/asound","/proc/bus","/proc/fs","/proc/irq","/proc/sys","/proc/sysrq-trigger"]},"windows":{"layerFolders":["C:\\ProgramData\\docker\\lcow\\5ba6a7b4fbdf9748ec89898be9bdaa911ee614436a475945638ab296b1155966","C:\\ProgramData\\docker\\lcow\\01fad57c971d672d91238a6c6ec21376e033006ec4c26563e91e7288cfb3bfeb"],"hyperv":{},"network":{"endpointList":["D615E3D5-B6AA-401E-A0A0-72581FA47059"],"allowUnqualifiedDNSQuery":true}}}}.
I've tried various logs (e.g. Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Compute-Operational and Get-EventLog -LogName Application -Source Docker) but cannot see any additional information about the error.
Can anyone advise if it is possible to create custom Linux-based images on a Windows DSVM? If it is, can anyone advise what the problem may be or any additional troubleshooting steps I could take?
Thanks!
It is possible to create Linux container on Windows Server.
Although this is currently in experimental stage.
This article might help : https://www.b2-4ac.com/lcow-linux-containers-on-windows-server/
I have vs code configured to use the git bash as a terminal in windows 7.
"terminal.integrated.shell.windows": "C:\Program Files\Git\bin\bash.exe"
I have enabled SSH key based authentication to remotely access a host. All this works fine from within the terminal in VS Code.
However, when using the vscode-remote SSH extension to connect to host I get an error because it tries to connect using "The terminal process command 'cmd.exe'" instead of git bash.
I've checked my terminal settings configuration in vs code and it points to git bash.exe
I've used the terminal extension in vs code and it opens a git bash and successfully connects to the host
Is there a setting that I'm missing to force Remote-SSH to use the git bash for the connection?
JerryL's answer lead me to realize, that I can simply set GIT's ssh path c:\Program Files\Git\usr\bin\ssh.exe in the remote.SSH.path setting of VS Code Preferences:
Then it just worked like a charm.
Just for clarity my VS Code version is: 1.40.0-insider (system setup)
I ran into a similar issue trying to get MS VS Code Studio Remote-SSH working with Putty's Pageant. I had Git for Windows installed and in a Git Bash shell, I could ssh and pick up the Pageant keys and no password was needed.
But VS Code Remote-SSH, while using the Git ssh in C:\Program Files\Git\usr\bin\ssh.exe was using Windows 7 cmd.exe shell which didn't talk to Pageant.
What worked for me on Windows 7, VS Code 1.36.1 with (Remote Development 0.15.0, Remote-SSH 0.44.0) and Git for Windows 2.22:
Start Pageant (C:\Program Files\PuTTY\pageant.exe) and Add key.
Start the ssh agent shim (C:\Program Files\Git\cmd\start-ssh-pageant.cmd). This takes care of the communication between Git ssh, which looks for ssh-agent, and Pageant.
Create the SSH_AUTH_SOCK environment variable
Control Panel / System / Advanced Settings / Environment Variables..
User variables for username / New..:
Variable name: SSH_AUTH_SOCK
Variable value: /tmp/.ssh-pageant-username (e.g. /tmp/.ssh-pageant-bill) (Environment Variable assignment screenshot)
Test ssh:
Open a command prompt: Enter set to view the list of Environment Variables. Is the SSH_AUTH_SOCK variable set correctly to something like /tmp/.ssh-pageant-bill?
Try ssh to your host using Git's ssh.exe: c:\Program Files\Git\usr\bin\ssh.exe user#host If this works, then VS Code Remote-SSH should work.
Finally, I added Pageant and start-ssh-pageant.cmd to my Windows 7 Startup so this persists across reboots.
Hope that helps.
Jerry.
I had a similar problem trying to get VS Code Remote use Putty Pageant.
1. Create .bat file somewhere with the following content:
echo OpenSSH
"C:\YOUR_PATH_HERE\PLINK.EXE" -ssh %*
2. Open VS Code settings, type remote ssh path in search and find Remote.SSH: Path settings
3. Past here path to your .bat file
4. Now VS Code Remote will use Pageant correctly.
I've created a docker container that contains a mssql Database. On the command line ip a gives an ip address for the container, however trying to ssh into it username#docker_ip_address yields ssh: connect to host ip_address port 22: Connection refused. So I'm wondering if I am even able to ssh into the container so I don't have to always be using the docker tool docker exec .... and if so how would I go about doing that?
To ssh into container you should full-fill followings
SSH server(Openssh) should be installed within the container and ssh service should be running
Port 22 should be published from container (when you run the container).more info here > Publish ports on Docker
docker ps command should display mapped ports 22
Hope above information helps for you to understand the situation...
If your container contains a database server, the normal way to interact with will be through an SQL client that connects to it; Google suggests SQL Server Management Studio and that connector libraries exist for popular languages. I'm not clear what you would do given a shell in the container, and my main recommendation here would be to focus on working with the server in the normal way.
Docker containers normally run a single process, and that's normally the main server process. In this case, the container runs only SQL Server. As some other answers here suggest, you'd need to significantly rearchitect the container to even have it be possible to run an ssh daemon, at which point you need to worry about a bunch of other things like ssh host keys and user accounts and passwords that a typical Docker image doesn't think about at all.
Also note that the Docker-internal IP address (what you got from ip addr; what docker inspect might tell you) is essentially useless. There are always better ways to reach a container (using inter-container DNS to communicate between containers; using the host's IP address or DNS name to reach published ports from the same or other hosts).
Basically, alter your Dockerfile to something like the following - that will install openssh-server, alter a prohibitive default configs and start the service:
# FROM a-image-with-mssql
RUN echo "root:toor" | chpasswd
RUN apt-get update
RUN apt-get install -y openssh-server
COPY entrypoint.sh .
RUN cd /;wget https://gist.githubusercontent.com/spekulant/e04521d6c6e1ccffbd3455c673518c5b/raw/1e4f6f2cb32caf3a4a9f73b02efdcbd5dde4ba7a/sshd_config
RUN rm /etc/ssh/sshd_config; cp sshd_config /etc/ssh/
ENTRYPOINT ["./entrypoint.sh"]
# further commands
Now you've got yourself an image with ssh server inside, all you have to do is start the service, you cant do RUN service ssh start because it won't work - docker specifics, refer to the documentation. You have to use a Entrypoint like the following:
#!/bin/bash
set -e
sh -c 'service ssh start'
exec "$#"
Put it in a file entrypoint.sh next to your Dockerfile - remember to chmod 755 entrypoint.sh it. There's one thing to mention here, you still wouldn't be able to ssh into the container - the default SSH server configuration doesn't allow login into root account using a password. So you either change the configs yourself and provide it to the image, or you can trust me and use the file I created - inspect it with the link from Dockerfile - nothing malicious there, only a change from prohibit-password to yes.
Fortunately for us - MSSQL official images start from Ubuntu so all the commands above fit perfectly into the environment.
Edit
Be sure to ask if something is unclear or I'm jumping too fast.
I Try access pgAdmin4 via browser instaled in another Notebook with Linux Ubuntu 16.04 in the same network in my house, but not access.
In localhost... Ok
But REMOTELY... DOES NOT ACCESS
You need to add the following config options:
DEFAULT_SERVER = '0.0.0.0'
in config_local.py (in "pgAdmin4" folder).
If you also want to change the default port then also add
DEFAULT_SERVER_PORT = 5050
First change the line in config.py from DEFAULT_SERVER = '127.0.0.1' to DEFAULT_SERVER = '0.0.0.0'
Config.py is located in the same directory as pgAdmin4:
sudo find / -name "*pgAdmin4"
Start pgAdmin4 in the same directory (use tmux or as service to keep in background):
sudo python3 pgAdmin4.py
If you don't know the login, you can delete/move this file and restart pgAdmin.py:
sudo find / -name "*pgadmin4.db"
This should work on both Ubuntu Server and Desktop. You should preferably keep the 127.0.0.1 and use nginx or Apache in front.
Weird enough, in my case I have to manually run the command
$ pgadmin4
and then the dashboard will be presented in the default browser automatically.
It seems you are trying to open pgadmin client at server.
I suggest you to install pgadmin client from where you want to connect this , add server in pgadmin and do connect.
Tested on ubuntu 20.04
apt install pgadmin4-apache2
nano /usr/share/pgadmin4/web/config.py
Change 127.0.0.1 by 0.0.0.0
Don't forget to copy the key in the shell when you launch pgadmin4 in the remote web browser by replacing 127.0.0.1 by pgadmin4 host IP
E.G. : Something like this in your remote web-browser
http://192.168.1.56:43223/?key=5f45c8ee-4593-41d0-9ae1-06d6dd1d8280
PS : If you don't find config.py
apt install mlocate
updatedb
locate pgadmin4 | grep config.py$
All commands are in root don't forget sudo if you are not root
On macOS, I figured out that pgAdmin 4 web interface uses the port 61886.
Try to access it using http://localhost:61886/browser.
If not, run the command netstat -atp tcp | grep -i "listen" and check what ports are listening.