[OT] ping: "Name or service not known" (Linux)

[Volker Bartheld]

Hallo!

Vielleicht kann mir ja einer der hier anwesenden Unix-Spezis helfen.

- Linux Mint Mate in einer VirtualBox.
- Netzwerkadapter: Bridged.
- Computer/Browse Network: NAS RN214 namentlich sichtbar und auch die
Dateien darunter.
- RN214 hat allerlei SMB-Shares, teils via Anonymous zugänglich, teils
nur als angemeldeter User.
- ping rn214 von der Windowsmaschine geht:
"Pinging rn214 [fe80::7ad2:94ff:feb1:393d%11] with 32 bytes of
data..."
- Dito ping mintvm (der Name der VM)
- //rn214-volker/media /media/rn214-volker/media cifs noauto,users,credentials=/home/user/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0

in /etc/fstab geht nicht ("mount error: could not resolve address for
rn214: Unknown error")
- //10.0.0.22/media /media/rn214-volker/media cifs noauto,users,credentials=/home/user/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0
funktioniert (10.0.0.22 ist die IP-Adresse von rn214)
- ping localhost auf der VM geht, dito ping mintvm und ping heise.de.

Es sieht so aus, als könnte die VM den Namen rn214 im lokalen Netzwerk
nicht auflösen, aber ich bin gerade etwas überfragt, warum...

Vielen Dank im Voraus,
Volker

[Hanno Foest]

Am 04.04.23 um 19:34 schrieb Volker Bartheld:

> Es sieht so aus, als könnte die VM den Namen rn214 im lokalen Netzwerk
> nicht auflösen, aber ich bin gerade etwas überfragt, warum...

welchen DNS Server benutzt du denn? Meiner steht in der
/etc/resolv.conf, aber mit dhcp und systemd kann das sonstwas sein...

Hanno

--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

[Volker Bartheld]

On Tue, 4 Apr 2023 19:34:52 +0200, Volker Bartheld wrote:
> - //rn214-volker/media /media/rn214-volker/media cifs noauto,users,credentials=/home/user/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0
> in /etc/fstab geht nicht ("mount error: could not resolve address for
> rn214: Unknown error")
> - //10.0.0.22/media /media/rn214-volker/media cifs noauto,users,credentials=/home/user/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0
> funktioniert (10.0.0.22 ist die IP-Adresse von rn214)
> - ping localhost auf der VM geht, dito ping mintvm und ping heise.de.
> Es sieht so aus, als könnte die VM den Namen rn214 im lokalen Netzwerk
> nicht auflösen, aber ich bin gerade etwas überfragt, warum...

Ingrid möchte noch anmerken, daß sie natürlich SMB in Rente schicken und
auf NFS umstellen wird, sobald die letzte Windows-Maschine das Netzwerk
verlassen hat.

Ach ja: SMB3 Transportverschlüsselung ist global deaktiviert, wegen Win7
Client.

Linux Mint 20.1 "Ulyssa", falls das eine Rolle spielt.

Danke,
Ingrid

[Volker Bartheld]

On Tue, 4 Apr 2023 19:38:40 +0200, Hanno Foest wrote:
> Am 04.04.23 um 19:34 schrieb Volker Bartheld:
>> Es sieht so aus, als könnte die VM den Namen rn214 im lokalen Netzwerk
>> nicht auflösen, aber ich bin gerade etwas überfragt, warum...
> welchen DNS Server benutzt du denn? Meiner steht in der
> /etc/resolv.conf, aber mit dhcp und systemd kann das sonstwas sein...

user@mintvm:~$ ifconfig
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.34 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::791:7c01:7db9:940 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:e3:57:0e txqueuelen 1000 (Ethernet)
RX packets 90 bytes 10241 (10.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 145 bytes 16454 (16.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 55 bytes 6618 (6.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 55 bytes 6618 (6.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ipconfig vom Host sagt:

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::11a6:84c8:1226:b955%11
IPv4 Address. . . . . . . . . . . : 10.0.0.29
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.0.0.1

Ethernet adapter VirtualBox Host-Only Network:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::4132:198d:346e:3c4b%16
IPv4 Address. . . . . . . . . . . : 192.***.***.***
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Die Fritte ist der DHCP-Server (frit...@10.0.0.1) in /etc/resolv.conf
steht:

nameserver 127.0.0.53
options edns0 trust-ad

In der Linux Mint Netzwerkkonfiguration steht für das Gerät enp0s3 quasi
alles auf Default, IPv4 und IPv6 auf "Automatic (DHCP)", keine
zusätzlichen Server.

Danke,
Volker

[Volker Bartheld]

On Tue, 4 Apr 2023 19:38:40 +0200, Hanno Foest wrote:

> Am 04.04.23 um 19:34 schrieb Volker Bartheld:
>> Es sieht so aus, als könnte die VM den Namen rn214 im lokalen Netzwerk
>> nicht auflösen, aber ich bin gerade etwas überfragt, warum...
> welchen DNS Server benutzt du denn? Meiner steht in der
> /etc/resolv.conf, aber mit dhcp und systemd kann das sonstwas sein...

Allerdings heißt es da auch:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.

resolvectl status spuckt mir folgendes aus:

Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa

[...]
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test

Link 2 (enp0s3)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 10.0.0.1

, finde ich einigermaßen plausibel.

[onlinefloh]

Was mir auf die schnelle aufgefallen ist, weil es per IP-Adresse geht
und per Namensauflösung nicht: Willst Du //rn214 mounten oder wie oben
angegeben //rn214-volker ?? Was sonst noch zur Lösung beitragen könnte:
was spuckt denn ein "dig rn214" in der VM ausgeführt aus? IP-Adresse
oder Fehlermeldung?

Wenn Fehlermeldung, heißt der zu behandelnde Patient wohl
Namensauflösung. Was systemd da aber für Sperenzchen machen könnte kann
ich Dir mangels diesbezüglicher Erfahrung auch nicht sagen, bislang
kommen meine Systeme ohne Systemd aus...

Gruß,
Florian

[Volker Bartheld]

On Tue, 4 Apr 2023 20:26:36 +0200, onlinefloh wrote:
> Was mir auf die schnelle aufgefallen ist, weil es per IP-Adresse geht
> und per Namensauflösung nicht: Willst Du //rn214 mounten oder wie oben
> angegeben //rn214-volker ??

Copy-Paste-Fehler. Der Name ist schon konsistent //rn214 überall.

> Was sonst noch zur Lösung beitragen könnte:
> was spuckt denn ein "dig rn214" in der VM ausgeführt aus? IP-Adresse
> oder Fehlermeldung?

Kümmere ich mich morgen drum. Jetzt ist schon alles runtergefahren und
der wohlverdiente Feierabend eingeläutet. ;-)

> Wenn Fehlermeldung, heißt der zu behandelnde Patient wohl
> Namensauflösung.

Kann natürlich auch mit der VM bzw. der VirtualBox-Konfiguration
zusammenhängen. Eine physische Linuxkiste hat mit einer sehr ähnlichen
Konfiguration überhaupt kein Problem //rn214 zu sehen/mounten. Mei,
"sehr ähnlich" - wenn ich mich nirgends vertippt und keinen der dutzend
Konfigurationsschritte vergessen habe.

Ciao,
Volker

[Gregor Szaktilla]

Am 04.04.23 um 19:34 schrieb Volker Bartheld:

> ... Es sieht so aus, als könnte die VM den Namen rn214 im lokalen Netzwerk

> nicht auflösen, aber ich bin gerade etwas überfragt, warum...

Ich hatte kürzlich bei einem neu installierten Rechner ebenfalls
Probleme bei der Namensauflösung, obwohl ich alle meine Rechner brav in
allen /etc/hosts eingetragen hatte.
Als Ursache hat sich dann eine fehlende
order hosts,bind
Zeile in /etc/resolv.conf herausgestellt. Zudem scheint es so, dass man
mittlerweile manche Sachen nur durch einen kompletten Reboot
„reparieren“ kann. Ich könnte kotzen.

HTH

Gregor



--
Sehrsehr! Vielviel!

Jaja.

[Volker Bartheld]

On Tue, 4 Apr 2023 20:26:36 +0200, onlinefloh wrote:

> On 04.04.23 19:34, Volker Bartheld wrote:
>> - //rn214-volker/media /media/rn214-volker/media cifs noauto,users,credentials=/home/user/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0
>> in /etc/fstab geht nicht ("mount error: could not resolve address for
>> rn214: Unknown error")
>> - //10.0.0.22/media /media/rn214-volker/media cifs noauto,users,credentials=/home/user/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0
>> funktioniert (10.0.0.22 ist die IP-Adresse von rn214)
>> - ping localhost auf der VM geht, dito ping mintvm und ping heise.de.

> Was sonst noch zur Lösung beitragen könnte:
> was spuckt denn ein "dig rn214" in der VM ausgeführt aus?

user@mintvm:~$ dig rn214

; <<>> DiG 9.16.1-Ubuntu <<>> rn214
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49335
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;rn214. IN A

;; Query time: 7 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mi Apr 05 10:46:42 CEST 2023
;; MSG SIZE rcvd: 41

Sieht sehr nach einer DHCP-Geschichte aus. Ich habe mir jetzt nochmal
die physische Linuxkiste angeschaut und auch ein Mint Mate von USB-Stick
gebootet, da ist derselbe Ansatz vollkommen unauffällig.

Schätze man könnte die VirtualBox vielleicht noch irgendwie
konfigurieren (es gibt ja die Optionen "NAT", "NAT Network", "Bridged",
"Internal", "Host Only" und "Generic Driver" - allerdings sehe ich nur
bei "Bridged" überhaupt das NAS im Netzwerk), irgendwelche Ports
forwarden oder eine IP-Adresse als zusätzlichen DHCP-Server eintragen.

Aber eigentlich ist das die Zeit nicht wert. Ging mir nur darum, etwaige
Fallstricke bei der Linux-Migration möglichst frühzeitig zu erkennen,
bei Fehlern ggfs. zurückrollen zu können und nicht nach der Installation
dazusitzen, ohne Zugriffsmöglichkeit auf wichtige Daten.

Speziell Wine ist das so ein Kandidat, hat eine Weile gedauert, bis ich
herausgefunden hatte, wie man "Open With" mit meinem
Lieblingsbildverarbeitungstool einrichtet. Und eine E-Mail-Datenbank
aus TheBat in Evolution zu importieren, bedurfte auch einiger Umwege.

Nein, Thunderbird ist keine Option. Mit dem werde ich in 1000 Jahren
nicht warm. Und KMail konnte mich auch nicht so recht überzeugen.

Dann noch ein Nobrainer-Backup-Restore-Konzept, Epson-Scanner mit
VueScan benutzen (XSane mag ja für den Anfang ganz nett sein, mir
gefällt der Workflow von VueScan aber doch besser, insbesondere, da ich
meine Profile übernehmen kann), Kyocera-USB-Drucker im Netz freigeben,
usw.

Grüße,
Volker

[Kay Martinen]

Am 04.04.23 um 19:34 schrieb Volker Bartheld:

> Vielleicht kann mir ja einer der hier anwesenden Unix-Spezis helfen.

...

> Es sieht so aus, als könnte die VM den Namen rn214 im lokalen Netzwerk
> nicht auflösen, aber ich bin gerade etwas überfragt, warum...

Zwei Fragen hab ich noch.

1. Warum fragst du das in de.sci.electronics?
2. Und warum nicht in einer linux-networking gruppe?

Du weißt doch schon das es an der namensauflösung liegt. Dann würde an
deiner stelle mal schauen wo auf dem system die namensauflösung erledigt
wird, durch welchen host. Vergleichen kannst du das ja mit den anderen
Systemen die das problem nicht haben.

Es könnte auch sein das beim mountversuch der resolver noch nichts
auflösen kann. Probiere es mit IP Adressen. Wenn es dann nicht klappt
liegt's offensichtlich beim mountversuch. Das alles ist kein
elektronik-Problem, sondern eines von linux netwerk -> Gruppenwechsel!

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Volker Bartheld]

On Wed, 5 Apr 2023 16:36:20 +0200, Kay Martinen wrote:
> Am 04.04.23 um 19:34 schrieb Volker Bartheld:
>> Vielleicht kann mir ja einer der hier anwesenden Unix-Spezis helfen.

> 1. Warum fragst du das in de.sci.electronics?
> 2. Und warum nicht in einer linux-networking gruppe?

Das ist strenggenommen nur eine Frage.

Die Antwort lautet: Weil ich hier in de.sci.electronics ein paar
freundliche Menschen mit Linuxerfahrung kenne, die mir bei solchen
Banalitäten möglicherweise sofort helfen können und bei denen nicht
klar ist, ob sie irgendwelche Linuxnewsgroups - die ich erst raussuchen
müßte - frequentieren. Zudem könnte es sein, daß es in solchen
Newsgroups vor noch mehr Blockwarten wimmelt, die gleich Schaum vor dem
Mund bekommen, wenn ein Lamer wie ich "Windows" schreibt, kein
"richtiges" Linux benutzt oder in sonst ein Fettnäpfchen tritt.

Meines Wissens gibt es hierzugroups keine Charta und wenn, dann kommt es
auf ein bißchen weniger SNR auch nicht mehr an. Oder welche
wissenschaftlichen Belange zum ohnehin nicht stattfindenden
Verbrenner-Aus 2035 mit Bezug zur Elektronik gab es zu diskutieren?

> Du weißt doch schon das es an der namensauflösung liegt. Dann würde an
> deiner stelle mal schauen wo auf dem system die namensauflösung erledigt
> wird

Das würde ich nur allzu gerne. Mangels Linux-Expertise mußte ich leider
fragen, das so präzise wie mir möglich. Und rätsle, Stand heute, immer
noch "wo auf dem system die namensauflösung erledigt wird" und warum
sie im Netzwerkbrowser funktioniert und in fstab nicht.

> durch welchen host. Vergleichen kannst du das ja mit den anderen
> Systemen die das problem nicht haben.

Message-ID: <12lx1b14pz7x$.d...@news.bartheld.net>

> Es könnte auch sein das beim mountversuch der resolver noch nichts
> auflösen kann.

Das wird bedarfsweise via noauto-Parameter in /etc/fstab getan:

//rn214/media /media/rn214/media cifs noauto,users,credentials=/home/user/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0

und funktioniert auch dann nicht, wenn ich das NAS im Netzwerkbrowser
(konkret: der Netzwerkumgebung im Dateibrowser) ebendiesen Systems
unter ebendiesem Namen bereits sehe.

> Probiere es mit IP Adressen.

Message-ID: <13firpf3...@news.bartheld.net>

Volker

[Helmut Harnisch]

Am 05.04.2023 um 16:59 schrieb Volker Bartheld:
> Das würde ich nur allzu gerne. Mangels Linux-Expertise mußte ich leider
> fragen, das so präzise wie mir möglich. Und rätsle, Stand heute, immer
> noch "wo auf dem system die namensauflösung erledigt wird" und warum
> sie im Netzwerkbrowser funktioniert und in fstab nicht.

Vielleicht hilt das
https://superuser.com/questions/641933/how-to-get-virtualbox-vms-to-use-hosts-dns
besonders die Antwort von Michael Samia, der vorschlägt, einen zweiten
Netzwerkadaper "host-only" auf der VM einzurichten.

[onlinefloh]

Hmm, da ich davon ausgehe, daß bei Dir lokal kein DNSSEC am Werk ist,
deutet das darauf hin, daß der Resolver in der VM nicht weiß, wo ihm
weitergeholfen wird und daher die Anfrage nicht beantworten KANN. Passt
auch zum Bild, daß es mit IP-Adresse statt mit Hostnamen funktioniert.
Das läßt immer noch mehrere mögliche Ursachen zu:
* Der DHCP-Server in Virtualbox rückt keine DNS-Info raus (die
DNS-Konfiguration in DHCP ist wie fast alles andere auch was man so
nutzen kann optional)
* Konfiguraton des systemd-Resolvers in der VM, so daß er per
DHCP-Option angelieferte DNS-Server nicht in Betracht zieht
* Konfiguration des DNS-Servers in der Fritzbox, so daß er Anfragen, die
nicht aus seinem eigenen Adressbereich kommen, nicht beantwortet, in
Verbindung mit nicht erfolgtem NAT bei unterschiedlichen Adressbereichen
in Virtualbox.

Vermutlich gibt's da noch ein paar weitere mehr oder weniger gut
getarnte Variationen, das Ganze zu Fall zu bringen...

Was ich aber sagen kann: den DHCP-server in Virtualbox und eventuelle
Probleme durch NAT (inklusive nicht erfolgtem NAT) kann man dadurch
umgehen, daß man das Netzwerk in VirtualBox auf Bridged stellt. Dann
verhält sich der Netzadapter in der VM so, als wäre er neben dem Host in
den Switch gestöpselt, insbesondere holt er sich auch seine Adresse
direkt von der angesprochenen Fritzbox. Klar, das ist nicht in jedem
Fall das was man eigentlich will, aber ich vermute hier passt es am
besten zu dem, was Du eigentlich mit der VM willst.

> Schätze man könnte die VirtualBox vielleicht noch irgendwie
> konfigurieren (es gibt ja die Optionen "NAT", "NAT Network", "Bridged",
> "Internal", "Host Only" und "Generic Driver" - allerdings sehe ich nur
> bei "Bridged" überhaupt das NAS im Netzwerk), irgendwelche Ports
> forwarden oder eine IP-Adresse als zusätzlichen DHCP-Server eintragen.
>

Wie gesagt, ich vermute "Bridged" kommt dem, was du vorhast, am
nächsten, dann hängt die VM ohne Umwege direkt mit im LAN. Aber wenn ich
das richtig verstanden habe, hast Du das ja schon so.
Bleibt also ganz oben auf der Liste die Konfiguration des
systemd-resolvers, dazu kann ich wie früher schon erwähnt mangels
Kontakt aber nix sagen.

Gruß,
Florian

[Volker Bartheld]

On Thu, 6 Apr 2023 09:20:36 +0200, onlinefloh wrote:
> Was ich aber sagen kann: den DHCP-server in Virtualbox und eventuelle
> Probleme durch NAT (inklusive nicht erfolgtem NAT) kann man dadurch
> umgehen, daß man das Netzwerk in VirtualBox auf Bridged stellt.

Message-ID: <13firpf3...@news.bartheld.net>

Zitat:

On Tue, 4 Apr 2023 19:34:52 +0200, Volker Bartheld wrote:

> - Linux Mint Mate in einer VirtualBox.
> - Netzwerkadapter: Bridged.

---------------------^^^^^^^

> - Computer/Browse Network: NAS RN214 namentlich sichtbar und auch die
> Dateien darunter.

Laß gut sein. Wenn das nur ein Phänomen der VM ist, kann ich damit
leben. Ist eh nur meine Sandbox für den Linux-Umzug.

Ciao,
Volker

[Marc Haber]

Volker Bartheld <news...@bartheld.net> wrote:
>Vielleicht kann mir ja einer der hier anwesenden Unix-Spezis helfen.

Mit einem Monat Verspätung habe ich leider auch keine Hilfe, aber
"Name or service not known" ist im SMB/CIFS Umfeld nicht
notwendigerweise ein DNS-Problem. Und SMB/CIFS ist ein fieses Thema,
weil man sich dafür sowohl mit Unix als auch im Windows auskennen
muss, und zwar so richtig tief drin und weit unten.

Zusammengefasst: Ich bin draußen, herzliches Beileid.

Grüße
Marc, dessen SMB servierender Scanner seit einigen Wochen schon wieder
nicht mehr SMB so serviert dass die Linuxe dieses SMB einhängen wollen
und der deswegen schon wieder SD-Karten durch die Gegend trägt
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834