EOS machine cannot be pinged from other machine on the same local network

Hi, I switched from MX Linux and EOS has been great so far. I have one question regarding my home network. Here’s my hardware info: https://clbin.com/s7l9A

I have a machine where EOS Apollo is installed (host A). I have another machine that has Mint (host B). I also have other machine that has MX Linux (host C). All of them are connected via Linksys router. All hosts have no issue connecting the internet. All of them are taking IP from DHCP automatically from the router.

The issue I’m facing is when I tried to ssh into host A from host B using the host name (i.e. ssh hostA), I can’t seem to do so. It says

ssh: Could not resolve hostname hostA: Name or service not known

I then tried to ping to host A from host B, it says

ping: hostA: Name or service not known

When I do the same (ssh and ping) from host C to host A, both works as expected. Likewise I can ssh/ping to host C from host A. I can actually ssh/ping to host B from host A as well. It’s just that I can’t do the same only from host B to host A.

I tried ssh and ping from host B to host A using the IP of host A. It works. I can ping and ssh from host B to host A.

This started happening, naturally, because I installed EOS on host A. But at the same time I installed Mint on host B.

Can someone direct me where to look, so that I can ssh/ping with host name?

Thanks in advance.

This is because of the firewalld being enabled by default on new installs

For more information:

1 Like

Thanks for your reply. Though I must say, that doesn’t seem to be the cause in my case.

For one. As of now, I can ping/ssh from host C (MX) to host A (EOS) no problem. It’s just that ping/ssh from host B (Mint) to host A (EOS) is the problem.

For firewalld, it was indeed active when I checked right after I saw your reply. So I turned it off by

sudo systemctl stop firewalld

And it’s now deactivated for the testing purposes.

$ systemctl status firewalld
○ firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Wed 2022-06-01 08:42:11 +08; 9s ago
Duration: 10min 8.216s
Docs: man:firewalld(1)
Process: 310914 ExecStart=/usr/bin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=exited, status=0/SUCCESS)
Main PID: 310914 (code=exited, status=0/SUCCESS)
CPU: 920ms

Jun 01 08:32:00 hostA systemd[1]: Starting firewalld - dynamic firewall daemon…
Jun 01 08:32:02 hostA systemd[1]: Started firewalld - dynamic firewall daemon.
Jun 01 08:42:11 hostA systemd[1]: Stopping firewalld - dynamic firewall daemon…
Jun 01 08:42:11 hostA systemd[1]: firewalld.service: Deactivated successfully.
Jun 01 08:42:11 hostA systemd[1]: Stopped firewalld - dynamic firewall daemon.

I still cannot ping/ssh from host B (Mint) to host A (EOS), with same error.

ssh: Could not resolve hostname hostA: Name or service not known

ping: hostA: Name or service not known

Any help would be appreciated. Thanks.

If you try to ping the host A (EOS) form host B (mint) by using the IP address of host A, does it work?

To find the IP address of host A (EOS) in eos

ip addr
2: enp37s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 70:85:c2:8a:53:b4 brd ff:ff:ff:ff:ff:ff
    inet brd scope global dynamic noprefixroute enp37s0
       valid_lft 6610sec preferred_lft 6610sec
    inet6 fe80::987c:e3fb:5da5:1570/64 scope link noprefixroute

The line inet 192.168.0.XXX is the IP Address of the eos machine

If the ping works using the IP address, then in the host B (mint) /etc/hosts file add the hostname of the eos machine.


Thanks Pudge. Adding the IP address of host A (EOS) into /etc/hosts of host B (Mint) partially solved my issue. I’m now able to ping/ssh host A from host B using a host name.

All of my local machines are obtaining the IP via router’s DHCP. I’m no pro on networking but this means the IP address they obtain may change upon rebooting, correct? If I were to put a static IP address into /etc/hosts it’s not always going to work.

Also I looked up /etc/hosts on host C (MX). The file is as clean as it can be. localhost hostC

The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Yet, this host C (MX) can ping/ssh host A (EOS) no problem. Why is this the case?

Sorry if I’m asking beyond EOS’s domain, I really need to learn more of networking stuff myself. Would be great if you can give me a pointer.


Might be

  • the dns configuration on the router or mint?
  • firewall rules on mint?

The usual use case for a file server, or media server, is to have all your pertinent data on one common source. This makes it easier to backup all your important data in one place, and all the client computers can have smaller storage devices because the home directory is not clogged with mp3, image files, etc.

The most common way to set up a network, is to have one computer set up as the SERVER with a static IP address, and the rest of the computers are set up as CLIENTs.

Then all the Client computers will have the hostname and static IP address of the Server in their /etc/hosts file.

The following explains one way to set up a client computer once the server is set up in easy small steps.

computer A -------- computer B ---------computer C
Computer B is the server. Computers A & C are clients.
If someone on computer A wants to exchange a file with Computer C, then I send the file to computer B in a folder named “relay”. Then the person on Computer C can retrieve the file. The server relays the file from A to C. If the file is important, It can be sent to a more permanent folder on the server for storage instead of the relay folder.

Again, in most use cases, the server is usually set up with the server’s OS on one small storage device. Then ALL the DATA is stored on a single large storage device. Then the administrator can use rsync periodically to backup the DATA storage device on another storage device of the same size. Preferably the DATA and DATABKUP devices would be identical devices, but the DATABKUP device can be larger than the DATA device. But with rsync, it can’t have a smaller DATABKUP than the DATA device.

If the DATA storage device fails, the DATABKUP device can be swapped out with the defective device, change the /etc/fstab file accordingly and you are back in business.

The DATABKUP device should be in a USB 3 enclosure. Then the DATABKUP device is normally not physically connected to the server except for when syncing the DATA. Thusly it receives little powered up time, and is safe from lightning, power supply failure on the server, and other catastrophic events.

In the meantime, the DATA storage device is usually powered up 24 hrs a day, 7 days a week. It also receives the daily writes to the storage device, and SSDs have a finite number of writes to every cell. Therefore I annually swap the physical DATA device with the DATABKUP device. This is a load sharing type of thing and should make the storage devices last longer.


Thanks all.

Pudge, thanks for your detailed explanation. While I understand the standard of setting up a server/client relationship, what I want to achieve now is slightly different. In my case, I don’t want any of my host that’s connected to the router be a server, I want to build it in a way that they can be server or client as the need rises (ssh’ing back and forth from both directions without static IP that is). In my previous configuration, I had 3 MX Linux connected to the router and, I was indeed able to do exactly that. So I’m trying to figure how.

Nonetheless, I think my problem lies more in the host B (Mint) as host A (EOS) and host C (MX) can interchangeably ssh from each direction. And it has to be something to do with DNS, as ssh with IP works. I’ll research more from Mint side.


1 Like

Coming back to this as I resolved the case. It was a firewall on Mint side (host B). Once turned off (or set the permission properly to let ssh through), ssh from both direction worked like a charm.

Again thanks for all your inputs. Great community. Think I’ll stay in EOS for a long time.


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.