Ok, dann sollte die Multichannelunterstützung eigentlich funktionieren (ist ab Version 3.0 implementiert)
Dann wäre meine letzte Vermutung tatsächlich, dass Win 10 Probleme bereitet wenn Gastzugänge bereit gestellt werden. Hier habe ich einen Beitrag gefunden der Beschreibt, wie du mit einer Änderung der Registry das Problem umgehen kannst.
https://techjourney.net/cannot-connect…-in-windows-10/
Beiträge von symsym
-
-
Ok, dann bin ich vorerst mit meinem rudimentären Wissen am Ende xD
Ein paar mehr Infos wären aber bestimmt nicht verkehrt.
Welche Distr. hast du auf dem Raspi überhaupt installiert?
Welche Version von Samba läuft darauf? Bitte einmal die Ausgabe von
hier posten. Vielleicht haben dann auch mehr Leute eine IdeeNachtrag: Eine kurze Suche durch das Netz hat mir verraten, dass Win 10 Probleme bereitet wenn die Samba-Freigabe einen Gast-Zugang erlaubt. Du könntest Probeweise in der /etc/samba/smb.conf mal den Gast-Zugang für deine Freigabe verbieten und dann neu Versuchen.
-
Hast du schon versucht dich einmal direkt mit der IP anzumelden anstatt dem hostname? Könnte ein DNS Problem sein.
Welches OS läuft denn auf dem Rechner mit dem du auf die Freigabe zugreifen kannst? Auch Windows 10?
Verwendest du jedes mal den gleichen Anmeldenamen + Passwort? -
Hast du an dem Pi noch externe Laufwerke (Festplatte, Stick, ...) angeschlossen? Hatte neulich ein ähnliches Problem und es lag daran, dass mein Pi die externen Geräte nicht mehr so erkannt hatte, wie sie in der fstab eingetragen waren. Soll heißen: /dev/sda war jetzt /dev/sdb und umgekehrt. Der Raspi hatte sich dann in den Emergency Mode versetzt und verlangt direkt das root Passwort. Wenn du also einen Monitor anschließt und dich im Emergency Mode wiederfindest, solltest du unbedingt einmal mit
deine Laufwerkbezeichnungen kontrollieren und mit der fstab abgleichen.
-
Hallo zusammen
Ich betreibe nun seid einigen Monaten meinen ersten Raspi 2 zu Hause und hab mich recht erfolgreich mit diversen Tuturials (auch aus diesem Forum, danke dafür:) ) durchschlagen können, doch nun stehe ich vor einem Problem für das es wohl keine 0815 Lösung zu geben scheint.
Der Raspi 2 läuft als Download- und Cloud-Server (pyLoad und ownCloud), für die Cloud ist ein 14 GB USB Stick mit ext4 angeschlossen, für pyLoad eine externe 2,5" Festplatte mit 1TB und NTFS. Damit die Platte ohne aktiven HUB läuft, ist die USB Spannung angehoben.
Etwa 3 Monate lang lief der Raspi ohne Probleme, doch seid ein paar Tagen stoppen, bzw. pausieren alle größeren Downloads ohne ersichtlichen Grund dafür. Dabei kommt es nicht zu einem Abbruch, sondern die Downloadrate fällt zunächst langsam ab und geht dann auf 0, nach einiger Wartezeit läuft der Download dann wieder an. Das Problem tritt sowohl bei pyLoad (mit Speicherort auf der externen Platte), als auch mit wget mit Speicherort auf der SD-Karte auf. Die Netzwerkverbindung bleibt jedoch ganz normal bestehen, ich kann dauerhaft mit ssh auf den Raspi zugreifen, das WebUI von pyLoad aufrufen oder auch die Cloud. Das problem habe ich bisher auch nur auf meinem Raspi beobachten können, andere Rechner im Netzwerk laufen ganz normal.Für die Netzwerkdaten habe ich mal das Script aus dem angepinnten Thread laufen lassen:
Spoiler anzeigen
Code
Alles anzeigenraspiNetInfo.sh V0.2.6e --- RNI010I: Starting collection of data and network analysis. This may take some time ... --- RNI012I: Ping of 74.125.136.147 successful --- RNI012I: Ping of www.google.com successful --- uname -a Linux RoPi 3.18.0-trunk-rpi2 #1 SMP PREEMPT Debian 3.18.5-1~exp1.co1 (2015-02-02) armv7l GNU/Linux --- [ -d /home/pi/.xbmc ] no --- ifconfig (eth und wlan) eth0 Link encap:Ethernet HWaddr @@:@@:@@:@@:@@ inet addr:192.168.2.31 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: @:@:@:@:@:@:@:@/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10615248 errors:0 dropped:0 overruns:0 frame:0 TX packets:7721784 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3641010592 (3.3 GiB) TX bytes:2809336962 (2.6 GiB) --- cat /etc/resolv | grep -i "nameserver" nameserver 192.168.2.1 --- cat /etc/network/interfaces source-directory /etc/network/interfaces.d allow-hotplug eth0 iface eth0 inet static address 192.168.2.31 netmask 255.255.255.0 gateway 192.168.2.1 network 192.168.2.0 --- cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 owncloud 192.168.2.106 HTPC --- route -n | egrep "(eth|wlan)" 0.0.0.0 192.168.2.1 0.0.0.0 UG 1024 0 0 eth0 10.8.0.0 192.168.2.31 255.255.255.0 UG 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.1 0.0.0.0 255.255.255.255 UH 1024 0 0 eth0 --- RNI016I: Check raspiNetInfo.log for sensitive data before publishing
Hoffe ihr könnt mir weiter Helfen
LG
edit: Habe noch etwas im debug log von pyLoad gefunden, kann damit aber nichts anfangen:
Code770 29.09.2015 15:15:17 DEBUG Resume File from 71708913 771 29.09.2015 15:23:20 DEBUG Chunk 1 failed: (28, 'Operation too slow. Less than 5 bytes/sec transferred the last 30 seconds') 772 29.09.2015 15:23:20 DEBUG Chunk 1 failed: (28, 'Operation too slow. Less than 5 bytes/sec transferred the last 30 seconds') 773 29.09.2015 15:23:20 DEBUG pycurl exception 28: Operation too slow. Less than 5 bytes/sec transferred the last 30 seconds 774 29.09.2015 15:23:20 WARNING Couldn't connect to host or connection reset, waiting 1 minute and retry. 775 29.09.2015 15:23:20 DEBUG pycurl exception 28: Operation too slow. Less than 5 bytes/sec transferred the last 30 seconds 776 29.09.2015 15:23:20 WARNING Couldn't connect to host or connection reset, waiting 1 minute and retry.
Gibt es evtl. auch ein Log, wo ich mehr infos über wget finde?
Update (01.10.15): Habe dieses Phänomen auch bei einem Debian live system (Desktop Rechner) und wärend einer Installation von Archlinux (VM) beobachten können. (Ich experimentiere derzeit viel in der für mich neuen Linux Welt^^) Unter Windows bisher keine Probleme, aber vll kommt der von mir eingesetzt Downloadmanager einfach besser mit kurzen Verbindungsabbrüchen zurecht. Da es sich aber offensichtlich nicht um ein Problem mit dem Raspi handelt, werde ich mal Richtung ISP nachforschen. Falls doch noch jemand den ein oder anderen guten Tipp für mich hat, nehme ich den gerne an