staging.inyokaproject.org

Hallo,

ich habe vor einer halben Stunde mit Etherape und Ethstatus 2 Netzwerkanalyse-Tools installiert. Seither machen meine Netzwerkfreigaben mit AutoFS Probleme. Vom Notebook aus kann ich problemlos auf meine Freigaben zugreifen. Das Problem scheint also beim Clienten zu liegen.

Zugriffe auf meine Freigaben dauern sehr lange oder schlagen komplett fehl. Direkt nach der Installation der o.g. Tools funktionierte nicht einmal mehr Ping im Heimnetzwerk (Internet lief problemlos), nach einem Reboot dauert nur noch AutoFS lange. Einfach smb://192.168.10.23 in Thunar eingeben geht. Auch Zugriff über Temrinal auf AutoFS geht nicht oder dauert lange. AutoFS hab ich bereits neu installiert und mehrfach neu gestartet. Die o.g. Tools sind auch wieder deinstalliert, kann es sein, dass sie irgendwas an der Netzwerkkonfiguration geändert haben?

Das sind die AutoFS-Dateien:

+dir:/etc/auto.master.d
+auto.master
/autofs /etc/auto.netzwerk      browse

fritzbox   -fstype=cifs,uid=1000,vers=1.0,username=user,password=passwort    ://192.168.10.1/usb-flashdrive

raspberry-pi-usb        -fstype=nfs,rw,soft,rsize=8192,wsize=8192       192.168.10.23:/media/usb/
raspberry-pi-home       -fstype=nfs     192.168.10.23:/home/pi/

Auf der Fritzbox läuft ein Samba-Server, auf dem Pi ein NFS-Server. Wenn der Ordner "fritzbox" aufgerufen wird, sehe ich auch die Dateien darin, wenn "raspberry-pi-usb" aufgerufen wird, werden keine Dateien angezeigt. Grds. machen aber beide Probleme.

Wenn ich mehr Ausgaben posten soll, liefere ich die nach.

Geht es

1. nur um die Freigaben oder

2. beobachtest Du auch generelle Fehler beim Netzwerk?

Im ersten Fall bist Du mit diesem Problem wahrscheinlich im Forum „Serverdienste und Dateifreigaben im Netzwerk“ besser aufgehoben, im anderen Fall zeige zunächst vom gestörten Rechner aus die Ausgaben dieser Befehle:

ip -br link ; ip -4 addr ; ip -4 route
ping -c1 GATEWAY # GATEWAY durch die IPv4-Adresse Deines lokalen Routers ersetzen!
ping -c1 213.95.41.4
host ubuntuusers.de ; echo $? 

Muss mich hier nochmal korrigieren: Der Zugriff auf den NFS-Server erfolgt nur von meinem Problemrechner aus, alle anderen nutzen Samba. Das hatte ich vergessen. Hab jetzt erstmal auf Samba umgestellt.

Ich glaube aber, dass es hier um ein ganz anderes (schon früher ähnlich aufgetretenes) Problem geht. Wenn ich hier auf NFS zugreifen wollte und Thunar nicht mehr reagierte gab es auch andere Effekte, die nichts mit Thunar oder Netzwerk zu tun hatten. z. B. konnte ich keine Desktop-Dateien auf dem Desktop mehr anklicken, auch Elemente im Papierkorb waren nicht mehr löschbar. Da kam eine Fehlermeldung, dass kein Zugriff auf den entsprechenden Dienst (Trash) möglich ist. Das Problem hatte ich in ähnlicher Weise schon wenn ich mal größere Dateimengen von A nach B kopiert hab (auch ohne Netzwerk). Da hatte ich aber noch KDE oder zumindest KDE-Software im Einsatz und ich habe gedacht das Problem liegt an KDE (z. B. dem KIO-Slave). Das Problem hab ich unter 16.04 und 18.04 unter so ziemlich jeder Ubuntu-Installation, sowohl unter Xfce als auch KDE als auch Xfce mit KDE-Software (v.a. Dolphin).

Nutze jetzt keine KDE-Software mehr und das Problem trat bisher überhaupt nicht auf. Was der Zugriff auf die Desktopdateien mit Netzwerk oder dem kopieren von Dateien zu tun haben ... ❓ Hardwareprobleme schließe ich aus, da ich seit dem ersten Einsatz von 16.04 so ziemlich alles an meiner Hardware ausgetauscht habe.

ip -br link ; ip -4 addr ; ip -4 route
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
enp5s0           UP             b0:6e:bf:c4:68:89 <BROADCAST,MULTICAST,UP,LOWER_UP> 
wlx000272a93656  DOWN           00:02:72:a9:36:56 <NO-CARRIER,BROADCAST,MULTICAST,UP> 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.10.21/24 brd 192.168.10.255 scope global noprefixroute enp5s0
       valid_lft forever preferred_lft forever
default via 192.168.10.1 dev enp5s0 proto static metric 100 
169.254.0.0/16 dev enp5s0 scope link metric 1000 
192.168.10.0/24 dev enp5s0 proto kernel scope link src 192.168.10.21 metric 100

ping -c1 192.168.10.23
PING 192.168.10.23 (192.168.10.23) 56(84) bytes of data.
64 bytes from 192.168.10.23: icmp_seq=1 ttl=64 time=1.21 ms

--- 192.168.10.23 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.215/1.215/1.215/0.000 ms

ping -c1 213.95.41.4
PING 213.95.41.4 (213.95.41.4) 56(84) bytes of data.
64 bytes from 213.95.41.4: icmp_seq=1 ttl=56 time=36.9 ms

--- 213.95.41.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 36.906/36.906/36.906/0.000 ms

host ubuntuusers.de ; echo $? 
ubuntuusers.de has address 213.95.41.4
ubuntuusers.de has IPv6 address 2001:780:0:25:dead:beef:cafe:1
ubuntuusers.de mail is handled by 10 mx1.ubuntu-de.org.
ubuntuusers.de mail is handled by 20 mx2.ubuntu-de.org.
0

Deine Netzwerk-Konfiguration sieht völlig normal aus und das Netzwerk scheint auch grundsätzlich ordnungsgemäß zu funktionieren.

Fried-rich schrieb:

[…] Ich glaube aber, dass es hier um ein ganz anderes (schon früher ähnlich aufgetretenes) Problem geht.

Ja, ich glaube das auch.

[…] Das Problem hatte ich in ähnlicher Weise schon wenn ich mal größere Dateimengen von A nach B kopiert hab (auch ohne Netzwerk).

Ist dies eine zutreffende Beschreibung des Verhaltens: „Unter bisher unverstandenen Umständen wird der Rechner plötzlich unbedienbar.“ ?

Die üblichen Verdächtigen bei einem derartigen Verhalten sind:

1. Treiber der Grafikkarte stürzt ab – erzeugt in der Regel Spuren im Systemlog.

2. Arbeitsspeicher zu klein oder schlecht verwaltet – erzeugt in der Regel Spuren im Systemlog.

3. Arbeitsspeicher defekt. Kann mit memtest aus dem Boot-Menü überprüft werden.

Also Maßnahmen:

• memtest über Nacht laufen lassen.

• Nach einem frischen Ereignis Rechner neu starten und das Systemlog untersuchen, nicht nur das aktuelle, sondern insbesondere auch die früheren Dateien /var/log/syslog*!

• Swap bereitstellen.

• Von 32-Bit-System (i386) umsteigen auf 64-Bit-System (x86_64), diese Kernel ermöglichen eine bessere Verwaltung des Arbeitsspeichers.

Du bist mit Deinem Problem aber spätestens jetzt hier im falschen Forum. Bitte beende diesen Thread und wende Dich nach Deinen Untersuchungen an ein besser geeignetes Forum.