staging.inyokaproject.org

Hallo! Ich habe einen File/TV-Server mit Windows 7 am laufen. Um Energie zu sparen, geht der Server automatisch in den Standby Modus, wenn er im Idle läuft. Wenn dieser dann wieder aufwacht, kann ich von meinem Ubuntu 14.04 System nicht mehr drauf zugreifen (von anderen Windows Rechner geht es). Wenn ich den Server im Nautilus öffnen möchte, bekomme ich folgende Fehlermeldung: Empfangen der Freigabenliste vom Server ist gescheitert. Die Wartezeit für die Verbindung ist abgelaufen. Wichtig zu erwähnen ist, denke ich, dass ich trotzdem noch über Kodi TV Empfangen kann. Wenn ich den Server dann wieder komplett ausschalte und wieder anschalte, dann funktioniert alles wieder. Geht er nun wie gewollt in Standy und wacht wieder auf, fängt das Spiel von vorne an. Ich hoffe ihr könnt mir bei diesem Problem helfen, denn ein File Server auf den man nicht zufgreifen kann, ist ja irgendwie Sinnlos 😀

MfG

Steffen

Hallo an alle,

ich habe hier die gleiche Fehlermeldung. Bei mir tritt der Fehler auf, nachdem ich mein Netbook für längere Zeit nicht an meinem Netzwerk angeschlossen hatte. Es könnte sein, dass mein letzter erfolgreicher Login des Netbooks ins Netzwerk vor der Version 16.04 gewesen ist, bin mir aber nicht unbedingt sicher.

Ich habe folgende Konfiguration: Desktop-PC: Ubuntu 16.04 Netbook: Ubuntu 16.04 Router: TP-Link, Archer VR900v

Mit einem Ping vom Netbook auf den Desktop-PC (auf die IP) bekomme ich sehr gute Rückmeldungen.

Komischer weise funktionieren Verbindungen vom Desktop-PC zum Netbook problemlos, in umgekehrter Richtung aber nicht.

Die Freigaben, smb-Nutzer und Server-Einstellungen habe ich mit Samba überprüft. Die sind noch alle so, wie sie vorher schon funktioniert hatten.

Kennt noch jemand dieses Problem, oder kann mir jemand eine Tipp geben, wie ich die Sache wieder ans Laufen bringe?

Ich nutze die Verbindung zum replizieren meiner geänderten Netbook-Dateien auf die Freigaben im Desktop mit Hilfe von Grsync. Die Freigaben lasse ich mir von Nautilus bei Start automatisch erstellen (wenn's denn wieder funktioniert).

MfG L-H

Hai ihr zwei,

kann es sein, dass sich die IP-Adresse nach dem aufwachen bzw. Wiederverbinden geändert hat? In dem Fall würde ich für beide empfehlen dem jeweiligen 'Server' eine fixe IP-Adresse zu spendieren.

@ LeoH,

du könntest in der 'reinen' Ubuntu-Umgebung auch RECHNERNAME.local in deiner Konfiguration verwenden. Denn die Rechner werden automatisch mit avahi kenntlich gemacht. Dann ist der Server unabhängig von der ggf. veränderten IP-Adresse stets mit eindeutigem Namen erreichbar.

@ SteffenNahnsen,

Windows 7... ist das eine neue Distribution? ☺

LG und Blubb

SCUBA

scuba schrieb:

kann es sein, dass sich die IP-Adresse nach dem aufwachen bzw. Wiederverbinden geändert hat? In dem Fall würde ich für beide empfehlen dem jeweiligen 'Server' eine fixe IP-Adresse zu spendieren.

Mein Server (der Desktop-PC) hat eine feste IP. Der Client (das Netbook) hat nach der erneuten Anmeldung wohl eine andere IP erhalten. Aber gerade die Verbindung vom Desktop zum Netbook funktioniert ja. Allerdings nur über die IP, nicht über den Namen.

@ LeoH,

du könntest in der 'reinen' Ubuntu-Umgebung auch RECHNERNAME.local in deiner Konfiguration verwenden. Denn die Rechner werden automatisch mit avahi kenntlich gemacht. Dann ist der Server unabhängig von der ggf. veränderten IP-Adresse stets mit eindeutigem Namen erreichbar.

Wo muss man das eintragen?

Gerade getestet:

1
2
3
4
5
6
7

leo@ubudeskt:~$ status avahi-daemon
status: Unbekannter Auftrag: avahi-daemon
leo@ubudeskt:~$ sudo status avahi-daemon
[sudo] Passwort für leo: 
status: Verbindung zu Upstart nicht möglich: Failed to connect to socket /com/ubuntu/upstart: Verbindungsaufbau abgelehnt
leo@ubudeskt:~$ sudo start avahi-daemon
start: Verbindung zu Upstart nicht möglich: Failed to connect to socket /com/ubuntu/upstart: Verbindungsaufbau abgelehnt

Die gleiche Meldung bekomme ich am Netbook auch. Kann das sein, dass da mit dem avahi-daemon etwas nicht stimmt?

MfG L-H

Hai LeoH,

ne, du hast da was mistverstanden... avahi läuft auf Ubuntu automatisch. Zum testen kannste ja mal ein

ping -c 3 RECHNERNAME.local

absetzen. Dann sollte der andere Rechner (RECHNERNAME) antworten.

Wenn du jetzt eine ssh oder sftp etc. Verbindung aufbauen willst, dann geht das klaglos; Bsp.

ssh RECHNERNAME.local

oder

ssh USER@RECHNERNAME.local

. Das geht auch mit gvfs... quasi allen lokalen Diensten und Rechnerverbindungen.

LG und Blubb

SCUBA

Hai LeoH,

da fällt mir noch ein, die meisten neueren WLAN-Router haben zwei WLAN-Netze mit unterschiedlichen IP-Adressbereichen. Du musst natürlich auch sicherstellen, dass die Rechner sich im gleichen IP-Bereich befinden. Hast du ggf. das Gast WLAN auch aktiviert? Meldet sich vielleicht das Netbook beim "wiederverbinden" im anderen WLAN an. Das kann geschehen wenn per 'Roaming' das stärkere Signal für die WLAN-Verbindung bevorzugt wird.

Allerdings dürfte auch dann die umgekehrte Verbindung vom DESKTOP zum Netbook nicht funktionieren... ist nur eine Idee.

LG und Blubb

SCUBA

Hallo scuba,

ich habe jetzt mal einiges getestet.

Auch wenn ich das Netbook über LAN verbinde und die WLAN-Verbindung deaktiviere erhalte ich die Fehlermeldung: ... "Die Wartezeit für die Verbindung ist abgelaufen."

Der Ping vom Desktop und vom Netbook auf den jeweiligen anderen Rechner mittels "RECHNERNAME.local" funktioniert.

Die Verbindung über ssh gelingt aber leider nur in der Richtung Netbook zum Desktop, umgekehrt leider nicht.

Das Mounten einer smb-Freigabe gelingt nur in der Richtung Desktop zum Netbook, umgekehrt leider nicht. Auch bei diesem Versuch eine Freigabe des Desktop aus dem Netbook heraus zu mounten erscheint die Fehlermeldung.."Wartezeit.."

Wie es aussieht, hängt die Sache unbedingt mit der langen Wartezeit zwischen der letzten Anmeldung des Netbooks am Netzwerk zusammen, also mit der Lease-Zeit der IP. Kann man so etwas irgendwie zurücksetzen?

MfG L-H

Hallo,
versuche es mal mit statischen ARP-Einträgen auf dem Server und ggf. auch auf dem Netbook. Von Vorteil wäre dann auch eine statische IPv4-Adresse auf den Netbbok. Viele Router weisen anhand der MAC-Adresse aber auch immer die selbe IPv4-Adresse zu. Soll so die selbe IP-Adresse für WLAN und LAN auf dem Netbook zugewiesen werden, kannst Du über den Network-Manager ganz einfach die MAC der WLAN-Karte für die Ethernetkarte kopieren.

Vorab temporär versuchen:

1

sudo arp -i <Interface> -s IPv4-Adresse MAC-Adresse

Permanente Einträge unter 14.04 über Skript in /etc/network/if-up.d bei Netzwerkstart erzeugen:

1
2

sudo touch /etc/network/if-up.d/static-arp 
sudo chmod +x /etc/network/if-up.d/static-arp 

Inhalt (Beispiel):

#!/bin/sh
arp -i eth0 -s 192.168.178.10 00:60:ff:10:20:31
arp -i eth0 -s 192.168.178.20 00:60:ff:10:20:32
arp -i eth0 -s 192.168.178.30 00:60:ff:10:20:33
...
# usw.

Hai LeoH;

vergleich doch bitte den Kernelstand beider Geräte mit

uname -a

Wenn ich nicht irre, ist kürzlich ein Samba Upgrade über die Repo's eingetroffen. Führe auf beiden Geräten einmal

sudo apt-get clean && sudo apt-get update && sudo apt-get dist-upgrade && sudo apt-get -f install && sudo apt-get --purge autoremove

aus, siehe auch Systempflege.

Die Verbindung über ssh gelingt aber leider nur in der Richtung Netbook zum Desktop, umgekehrt leider nicht.

Hast du denn auf dem Netbook den Openssh-server installiert? Denn in dem Augenblick wo der Netbook als Zielrechner fungiert, muss der ssh-server drauf laufen.

Wenn openssh-server installiert ist, benenne bitte das Verzeichnis ~/.ssh auf deinem Desktop um, dann versuche erneut mittels ssh RECHNERNAME.local eine Verbindung zum Netbook. Wenn das funktioniert, können wir entweder versuchen deine alten SSH-Schlüssel zu reparieren, oder wenn keine weiteren Schlüssel im alten ~/.ssh enthalten waren, die neuen Schlüssel verwenden. SSH mag das nicht, wenn sich die IP-Adressen des Servers "Ziel-Maschine" verändern!

Das Mounten einer smb-Freigabe gelingt nur in der Richtung Desktop zum Netbook, umgekehrt leider nicht. Auch bei diesem Versuch eine >Freigabe des Desktop aus dem Netbook heraus zu mounten erscheint die Fehlermeldung.."Wartezeit.."

Siehe doch bitte mal in der smb.conf Datei

less /etc/samba/smb.conf

nach ob die Arbeitsgruppe beider Rechner gleich sind. Das hört sich zwar komisch an, aber in unserem Netz hat diese kleine Einstellung ganz schön Probleme gemacht.

Sollte die Arbeitsgruppe unterschiedlich sein, kannst du sie anpassen... auf beiden Geräten mit

sudo nano /etc/samba/smb.conf

LG und Blubb

SCUBA

Hallo scuba,

habe mir heute mal wieder Zeit für mein Netzwerkproblem genommen und folgendes getestet, bzw ausgeführt.

1. Arbeitsgruppenname in der smb.conf in beiden Geräten in Kleinbuchstaben eingetragen. (vorherige Einträge waren unterschiedlich).

Ergebnis: Keine Auswirkung auf mein Problem !

2. Dem LAN-Anschluß auf dem Netbook eine feste IP zugewiesen.

Ergebnis: Keine Auswirkung auf mein Problem !

3. Systempflege mit deiner angegebenen Befehlskombination ausgeführt.

Ergebnis beim Desktop: Lief ohne Fehlermeldungen durch !

Ergebnis beim Netbook: Lief nicht durch, siehe u.a. Fehlermeldungen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

OK:1 http://archive.canonical.com/ubuntu xenial InRelease
Holen:2 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]                         
OK:3 http://de.archive.ubuntu.com/ubuntu xenial InRelease                                                    
Ign:4 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial InRelease                                           
OK:5 http://de.archive.ubuntu.com/ubuntu xenial-updates InRelease                                            
Ign:6 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial Release                      
Ign:7 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Sources                 
Ign:8 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 Packages
Ign:9 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main i386 Packages
Ign:10 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main all Packages
Ign:11 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de_DE
Ign:12 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de
Ign:13 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-en
Ign:14 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 DEP-11 Metadata
Ign:15 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main DEP-11 64x64 Icons
Ign:7 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Sources
Ign:8 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 Packages
Ign:9 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main i386 Packages
Ign:10 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main all Packages
Ign:11 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de_DE
Ign:12 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de
Ign:13 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-en
Ign:14 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 DEP-11 Metadata
Ign:15 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main DEP-11 64x64 Icons
Ign:7 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Sources
Ign:8 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 Packages
Ign:9 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main i386 Packages
Ign:10 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main all Packages
Ign:11 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de_DE
Ign:12 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de
Ign:13 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-en
Ign:14 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 DEP-11 Metadata
Ign:15 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main DEP-11 64x64 Icons
Ign:7 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Sources
Ign:8 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 Packages
Ign:9 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main i386 Packages
Ign:10 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main all Packages
Ign:11 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de_DE
Ign:12 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de
Ign:13 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-en
Ign:14 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 DEP-11 Metadata
Ign:15 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main DEP-11 64x64 Icons
Ign:7 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Sources
Ign:8 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 Packages
Ign:9 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main i386 Packages
Ign:10 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main all Packages
Ign:11 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de_DE
Ign:12 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de
Ign:13 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-en
Ign:14 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 DEP-11 Metadata
Ign:15 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main DEP-11 64x64 Icons
Fehl:7 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Sources
  404  Not Found
Ign:8 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 Packages
Ign:9 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main i386 Packages
Ign:10 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main all Packages
Ign:11 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de_DE
Ign:12 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-de
Ign:13 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main Translation-en
Ign:14 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main amd64 DEP-11 Metadata
Ign:15 http://ppa.launchpad.net/conduit/ppa/ubuntu xenial/main DEP-11 64x64 Icons
Es wurden 102 kB in 2 s geholt (42,2 kB/s).
Paketlisten werden gelesen... Fertig
W: The repository 'http://ppa.launchpad.net/conduit/ppa/ubuntu xenial Release' does not have a Release file.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: Fehlschlag beim Holen von http://ppa.launchpad.net/conduit/ppa/ubuntu/dists/xenial/main/source/Sources  404  Not Found
E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.

Ich habe in den Systemeinstellungen für "Anwendungen & Aktualisierungen" im Register "Andere Programme" alles, was mit ..ppa.launchpad.net.. zu tun hatte deaktiviert und den Befehl erneut ausgeführt. Diesmal lief die Systempflege auch am Netbook ohne Fehlermeldungen durch.

Allerdings besteht auch danach immer noch der Fehler, dass ich mich nicht vom Netbook auf den Desktop verbinden kann. Es erscheint immer noch die Fehlermeldung:

1

Unbekannte Fehlermeldung: Einhängen der Windows-Freigabe ist fehlgeschlagen: Die Wartezeit für die Verbindung ist abgelaufen.

4. Der Kernel ist bei beiden Geräten die Version: 4.4.0-59-generic

MfG L-H

Hallo ubuntuusers,

ich arbeite immer noch am Verbindungsproblem vom Netbook zum Desktop. Heute habe ich eine Unstimmigkeit im avahi-status entdeckt. Vielleicht hat das ja etwas mit meinem Problem zu tun. Hier die Ausgabe:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
   Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
   Active: active (running) since Sa 2017-02-25 10:49:13 CET; 20min ago
 Main PID: 2666 (avahi-daemon)
   Status: "avahi-daemon 0.6.32-rc starting up."
   CGroup: /system.slice/avahi-daemon.service
           ├─2666 avahi-daemon: running [ubucom.local
           └─2669 avahi-daemon: chroot helpe

Feb 25 10:49:13 ubucom avahi-daemon[2666]: No service file found in /etc/avahi/services.
Feb 25 10:49:13 ubucom avahi-daemon[2666]: Joining mDNS multicast group on interface enp4s0.IPv6 with address 2003:74:ca38:3601:3a63:bbff:fe80:1e
Feb 25 10:49:13 ubucom avahi-daemon[2666]: New relevant interface enp4s0.IPv6 for mDNS.
Feb 25 10:49:13 ubucom avahi-daemon[2666]: Joining mDNS multicast group on interface enp4s0.IPv4 with address 192.168.0.107.
Feb 25 10:49:13 ubucom avahi-daemon[2666]: New relevant interface enp4s0.IPv4 for mDNS.
Feb 25 10:49:13 ubucom avahi-daemon[2666]: Network interface enumeration completed.
Feb 25 10:49:13 ubucom avahi-daemon[2666]: Registering new address record for 2003:74:ca38:3601:3a63:bbff:fe80:1e7b on enp4s0.*.
Feb 25 10:49:13 ubucom avahi-daemon[2666]: Registering new address record for 192.168.0.107 on enp4s0.IPv4.
Feb 25 10:49:13 ubucom systemd[1]: Started Avahi mDNS/DNS-SD Stack.
Feb 25 10:49:14 ubucom avahi-daemon[2666]: Server startup complete. Host name is ubucom.local. Local service cookie is 2798791721.

Hier fällt mir die o.a. Zeile:

1

No service file found in /etc/avahi/services.

besonders auf.

Im Desktop ist an dieser Stelle eine Datei "udisks.service" mit allerhand Parameterangaben vorhanden. Kann, oder muß ich das beheben? Wenn ja, wie?

Nachtrag: Nach einem reboot ist die o.a. Fehlermeldung nicht mehr vorhanden. Die Datei udisks.services ist allerdings immer noch nicht vorhanden.

@scuba Die Verbindung mittels

1

ssh ubucom.local

nach Umbenennung des Verzeichnisses ~/.ssh habe ich eben getestet. Ergebnis:

1

ssh: connect to host ubucom.local port 22: Connection refused

Allerdings ist innerhalb des Ordnders "~/.ssh" nichts vorhanden das man ändern oder nutzen könnte. Openssh-Server ist allerdings auch nicht installiert.

Ich möchte noch erwähnen, dass mein /home auf dem Desktop verschlüsselt ist, das auf dem Netbook nicht. Vielleicht hat ja auch das eine Auswirkung. Allerdings war das schon immer so und hat damit auch schon funktioniert.

Gruß L-H

Hai LeoH,

1	ssh: connect to host ubucom.local port 22: Connection refused

du wirst jetzt lachen... just das beschriebene Problem hatte ich gestern mit einem neu aufgesetzten System 🙄 Lösung bei mir:

sudo apt remove --purge openssh-server openssh-client && sudo apt install openssh-server openssh-client

danach hat's wieder geflutscht.

Zu deiner AVAHI-Problematik fällt mir nichts mehr ein.

Für mich sieht es aus, als währen die Rechner in unterschiedlichen Netzabschnitten unterwegs... Einer im WLAN mit 192.168.2.xxx der andere im Gast-WLAN oder Kabelnetzwerk mit 192.168.3.xxx... aber das hast du ja schon ausgeschlossen... jedenfalls können die beiden Rechner nicht kommunizieren, bisher weder per SSH noch mit AVAHI (ZeroConf).

Da gibt es bestimmt den einen oder anderen findigen Ubuntuuser der dir weiter unter die Flossen greift.

LG und Blubb

SCUBA

Hallo Ubuntuusers,

hier ist wieder ein Beispiel (ich), wie blöd man sein kann.

Ich hatte irgendwann in der Zeit, als ich mein Netbook lange nicht zu Hause hatte am Desktop die Firewall aktiviert. 👿

Nach der Deaktivierung läuft nun meine Verbindung wieder in beide Richtungen super.

Für mich ist das Thema damit gelöst. 🙄

Tut mir Leid, wenn ich dadurch eure Zeit unnötig in Anspruch genommen habe. 😬

MfG L-H