Hallo Bernd
Das ist leider etwas missverständlich.
Was schaltet sich denn genau ab, der Dienst oder das komplette NAS?
Gruss
Micha
Hi,
bei mir das gleiche. Immer beim kopieren (aber nur im WLAN) von großen Dateien schaltet sich der Dienst am Book ab.
Nach einem remount, das gleiche.
Mach ich das über Lan ist alles i.o.
Dienst auf dem NAS läuft weiter ohne Fehler Meldung.
Sehr seltsam!
Gruß
Morgähn,
seit ihr sicher das es am NAS liegt? 
Bei mir funkt z.B. vom iMac die Timemachine über Airport nicht, verliert immer die Verbindung, über GB-Kabel funkt es aber prima?
Das MBP(2011) spackt mit max. 144 M/Bit herum, vom Kastrierten WinXP Rechner(Wlan "n") gehen fast 245 M/Bit über den Ähter,
über GB-Kabel wieder volle Leistung!?
Grüße HD
Hi,
das blöde ist, es kann auch an was anderem liegen.
Meine Hardware:
Qnap Pro TS 239Pro II+ ver.3.4.2 mit 4TB
MacBook Pro OSX 10.6.7
iMac 3.06GHz OSX 10.6.7
FritzBox 7390 ver.84.04.91
SLM2008 8-Port Gigabit Switch
In den Log`s ist nix zu sehen das was falsch läuft.
Der iMac schaufelt die Daten hin und her vom feinsten und das MacBook verliert die Verbindung nach einer Zeit (nur beim Kopieren). :-/
Werde mal verschiedene Situationen mal testen warum die Verbindung abbricht. :cry:
Bei mir das Gleiche beim Zugriff per AFP per WLAN.
(Habe das aktuelle Macbook Air)
per LAN habe ich noch nicht getestet.
Ich kann es ebenfalls reproduzieren,
- wenn man mehrere Zugriffe gleichzeitig hat (zB 2 Kopiervorgänge gleichzeitig)
- wenn man große Mengen kopiert (groß heißt über 100MB)
Die Fehlermeldung "Dienst nicht verfügbar" kommt dann nach einigen Minuten.
Wo soll ich anfangen zu suchen?
Scheint das gleiche Problem von diesem Thread zu sein: http://forum.qnapclub.de/viewtopic.php?f=49&t=14051&start=0
Oder diesem hier: http://forum.qnapclub.de/viewtopic.php?f=49&t=15558&start=0
Dateiserver wurde ausgeschalten --> nur, wenn man per WLAN mittels AFP auf den QNAP NAS zugreift und große Dateien kopiert.
Ich habe mal in meiner Konsole nach afp gesucht und folgendes Fehlerprotokoll gefunden. Vielleicht kann ja Terz was mit anfangen. (Wo ist er denn, der David, wenn man ihn braucht... 
)
05.06.11 09:33:52 kernel ASP_TCP CancelOneRequest: cancelling slot 7 error 89 reqID 39871 flags 0x9 afpCmd 0x14 so 0xf6a6048
05.06.11 10:18:14 KernelEventAgent[50] tid 00000000 type 'afpfs', mounted on '/Volumes/Datenspeicher', from 'afp_4knTCg3HL4dn10fLhQ0wOGnq-1.2e000003', not responding
05.06.11 10:18:14 kernel AFP_VFS afpfs_DoReconnect started /Volumes/Datenspeicher prevTrigger 0 currTrigger 1
05.06.11 10:18:14 kernel AFP_VFS afpfs_DoReconnect: doing reconnect on /Volumes/Datenspeicher
05.06.11 10:18:14 kernel AFP_VFS afpfs_DoReconnect: posting to KEA EINPROGRESS for /Volumes/Datenspeicher
05.06.11 10:18:14 kernel AFP_VFS afpfs_DoReconnect: Max reconnect time: 30 secs, Connect timeout: 15 secs for /Volumes/Datenspeicher
05.06.11 10:18:14 kernel AFP_VFS afpfs_DoReconnect: connect to the server /Volumes/Datenspeicher
05.06.11 10:18:14 kernel AFP_VFS afpfs_DoReconnect: Logging in with uam 8 /Volumes/Datenspeicher
05.06.11 10:19:02 kernel AFP_VFS afpfs_DoReconnect: Restoring session /Volumes/Datenspeicher
05.06.11 10:19:03 KernelEventAgent[50] tid 00000000 type 'afpfs', mounted on '/Volumes/Datenspeicher', from 'afp_4knTCg3HL4dn10fLhQ0wOGnq-1.2e000003', not responding
05.06.11 10:19:03 kernel AFP_VFS afpfs_DoReconnect: Primary Reconnect failed 5 on /Volumes/Datenspeicher
05.06.11 10:19:03 kernel AFP_VFS afpfs_DoReconnect: trying Secondary Reconnect on /Volumes/Datenspeicher
05.06.11 10:19:03 kernel AFP_VFS afpfsCheckOpenFiles: File <.Library.apdb-conch> can not be reopened due to deny modes or byte range locks.
05.06.11 10:19:03 kernel AFP_VFS afpfsCheckOpenFiles: File <.Properties.apdb-conch> can not be reopened due to deny modes or byte range locks.
05.06.11 10:19:03 kernel AFP_VFS afpfsCheckOpenFiles: File <.History.apdb-conch> can not be reopened due to deny modes or byte range locks.
05.06.11 10:19:03 kernel AFP_VFS afpfsCheckOpenFiles: File <.ImageProxies.apdb-conch> can not be reopened due to deny modes or byte range locks.
05.06.11 10:19:03 kernel AFP_VFS afpfsCheckOpenFiles: File <.BigBlobs.apdb-conch> can not be reopened due to deny modes or byte range locks.
05.06.11 10:19:03 kernel AFP_VFS afpfsCheckOpenFiles: File <.Faces.db-conch> can not be reopened due to deny modes or byte range locks.
05.06.11 10:19:03 kernel AFP_VFS afpfsCheckOpenFiles: File <IMG_1817.CR2> can not be reopened due to deny modes or byte range locks.
05.06.11 10:19:03 kernel ASP_TCP CancelOneRequest: cancelling slot 17 error 35 reqID 16774 flags 0x29 afpCmd 0x3C so 0xf698000
05.06.11 10:19:03 kernel ASP_TCP CancelOneRequest: cancelling slot 18 error 35 reqID 16775 flags 0x29 afpCmd 0x3C so 0xf698000
05.06.11 10:19:03 kernel ASP_TCP CancelOneRequest: cancelling slot 19 error 35 reqID 16776 flags 0x29 afpCmd 0x3C so 0xf698000
05.06.11 10:19:03 kernel ASP_TCP CancelOneRequest: cancelling slot 20 error 35 reqID 16777 flags 0x29 afpCmd 0x3C so 0xf698000
05.06.11 10:19:03 kernel ASP_TCP CancelOneRequest: cancelling slot 21 error 35 reqID 16778 flags 0x29 afpCmd 0x3C so 0xf698000
05.06.11 10:19:03 kernel ASP_TCP CancelOneRequest: cancelling slot 22 error 35 reqID 16779 flags 0x29 afpCmd 0x3C so 0xf698000
05.06.11 10:19:03 kernel ASP_TCP CancelOneRequest: cancelling slot 23 error 35 reqID 16780 flags 0x29 afpCmd 0x3C so 0xf698000
05.06.11 10:19:03 kernel ASP_TCP CancelOneRequest: cancelling slot 24 error 35 reqID 16781 flags 0x29 afpCmd 0x3C so 0xf698000
05.06.11 10:19:03 kernel AFP_VFS afpfs_DoReconnect: get the reconnect token
05.06.11 10:25:12 kernel AFP_VFS afpfs_unmount: /Volumes/Datenspeicher, flags 524288, pid 50
05.06.11 10:25:12 kernel ASP_TCP CancelOneRequest: cancelling slot 31 error 89 reqID 35504 flags 0x9 afpCmd 0x14 so 0xf698000
05.06.11 21:50:16 kernel AFP_VFS afpfs_mount: /Volumes/Datenspeicher, pid 282
05.06.11 21:51:10 kernel ASP_TCP CancelOneRequest: cancelling slot 6 error 89 reqID 10 flags 0x9 afpCmd 0x14 so 0xf789e94
05.06.11 21:51:28 kernel ASP_TCP CancelOneRequest: cancelling slot 6 error 89 reqID 10 flags 0x9 afpCmd 0x14 so 0xf789cf8
05.06.11 21:52:37 kernel AFP_VFS afpfs_DoReconnect started /Volumes/Datenspeicher prevTrigger 0 currTrigger 1
05.06.11 21:52:37 kernel AFP_VFS afpfs_DoReconnect: already in unmount /Volumes/Datenspeicher
05.06.11 21:52:37 kernel ASP_TCP CancelOneRequest: cancelling slot 11 error 89 reqID 4144 flags 0x29 afpCmd 0x3D so 0xf780670
05.06.11 21:52:37 kernel ASP_TCP CancelOneRequest: cancelling slot 12 error 89 reqID 4145 flags 0x29 afpCmd 0x3D so 0xf780670
05.06.11 21:52:37 kernel ASP_TCP CancelOneRequest: cancelling slot 13 error 89 reqID 4146 flags 0x29 afpCmd 0x3D so 0xf780670
05.06.11 21:52:37 kernel AFP_VFS afpfs_unmount: /Volumes/Datenspeicher, flags 524288, pid 334
05.06.11 21:56:34 kernel AFP_VFS afpfs_mount: /Volumes/Datenspeicher, pid 500
05.06.11 21:57:00 kernel ASP_TCP CancelOneRequest: cancelling slot 6 error 89 reqID 13 flags 0x9 afpCmd 0x14 so 0xf78351c
05.06.11 22:08:01 kernel AFP_VFS afpfs_unmount: /Volumes/Datenspeicher, flags 524288, pid 334
05.06.11 22:14:54 kernel AFP_VFS afpfs_mount: /Volumes/Datenspeicher-1, pid 500Hm, error 89 und error 35.
Habe gerade während des Copy und Paste schon wieder die Verbindung zum Dateiserver verloren. War gerade dabei Bilder über WLAN in die Aperture-Library zu kopieren. Hatte ich auch am 05.06. versucht, wie man im Logfile ja sehen kann.
Ach ja, habe die Firmware 3.4.3.0520T auf der ts410 laufen, greife mit OSX 10.6.7 per afp über eine Wlan-Verbindung (g) zu.
Der ist hier und liest 
Bei der FBF hatte ich auch Abbrüche über WLAN. Darum hatte ich mir 'ne Airport gekauft und die an der FBF dran. Seitdem keine Abbrüche mehr.
Irgendwie "Fluppt da ab und zu mal was weg, an der FBF".
Allerdings weiss ich auch, dass die Jungs von netatalk an den reconnection Problem arbeiten, welches für TimeMachine zwingend notwendig ist (Releasenotes von Netatalk 2.2 - aktuell beta).
(Der Reconnect kommt ja von einer "kleinen Trennung")
05.06.11 10:19:03 kernel AFP_VFS afpfs_DoReconnect: Primary Reconnect failed 5 on /Volumes/Datenspeicher
05.06.11 10:19:03 kernel AFP_VFS afpfs_DoReconnect: trying Secondary Reconnect onhttps://discussions.apple.com/…/2399684?start=0&tstart=0
http://support.grouplogic.com/?p=1568
Grüsse, David
FBF = Fritzbox?
wohin muss ich das netatalk installieren? auf dem qnap? oder ist das standardmäßig bereits implementiert?
Habe inzwischen per LAN Verbindung keinerlei Connection Probleme mehr! Das Problem ist nur wenn man WLAN verwendet da.
ZitatFBF = Fritzbox?
Richtig
Zitatwohin muss ich das netatalk installieren? auf dem qnap? oder ist das standardmäßig bereits implementiert?
Das ist der AFP Dienst der auf dem NAS läuft (FW 3.4.3 in der Version 2.1)
ZitatHabe inzwischen per LAN Verbindung keinerlei Connection Probleme mehr! Das Problem ist nur wenn man WLAN verwendet da.
Richtig, weil es dann, wenn alles richtig konfiguriert ist nicht zu einem reconnect kommt. Diesen "reconnect" hatte ich ebenfalls bei der FBF über WLAN, welcher sich eigentlich überhaupt nirgends anders bemerkbar macht, weil es nur einen bruchteil (Hundertstel) dauert. Weil netatalk diesen reconnect noch nicht "richtig" in griff hat, steigt's dann aus.
Mit der Airport Extreme fluppt aber auch das WLAN so stabil, dass ich einfach keinen reconnect (wie beim LAN) hab / zumindest sind das meine Erfahrungswerte / die andere User auch schon hatten. Da müsste man mal alte Posts raussuchen (bei bedarf).
Im Prinzip hängt das ganze 1x an Netatalk und 1x wenn man so möchte an den AP (Verbindungsabbrüche), welche mit Kabel oder anderen AP's durchaus minimiert / wegfallen können (die reconnects).
Netatalk ist aber gerade mit dem reconnect problem am basteln. In Zukunft sollte es je nachdem mit kleinen reconnects kein Problem mehr sein.
Grüsse, David
...ich habe genau das exakte Problem, und wunderte mich schon, woran es liegt 
Na dann hoffen wir mal, dass die Jungs von netatalk bald den "Primary Reconnect" implementieren.
Gruß
Dominik
Der ist bei NETATALK schon seit JUNI implementiert !!
Aber man braucht Version 2.2 und die kostet auf einmal KOHLE..
Nunja jemand wie QNAP sollte eigentlich wenn er auch Werbung für TIMEMACHINE macht sowas auch rechtzeitig implementieren...
Wir sollten daher alle mal DRUCK bei QNAO machen...
Tomas
Darüber gibt's im Englischen und hier forum schon genug Beiträge
wir drücken schon lange bei qnap :mrgreen: und qnap ist sich des problems auch schon lange bewusst. bereits weit vor der aktuellen "time machine not working with lion" sturmflut im englischen forum :roll:
ich könnte qnap höchstens noch schreiben "ich hab's euch ja gesagt", aber das würde auch nicht wirklich helfen
eine lösung ist in arbeit 
http://forum.qnapclub.de/viewt…9&t=16298&start=10#p91242
die "ich will kohle sehen" aktion von netatalk hat das ganze natürlich verzögert... inzwischen hat sich qnap aber anscheinend dazu durchgerungen, zu zahlen.
Deute mit den Finger darauf, auch wenn's nur einen Daumen iss :thumb: ich hab's euch ja gesagt
:mrgreen: :mrgreen:
haha! :tongue: Doofes Lion! :tongue: ich bleib bei windoof :mrgreen: :mrgreen: :mrgreen:
fehlt nur noch die Wasserdicht App für den Mac! :tongue: :tongue: :mrgreen: :mrgreen: :mrgreen: :mrgreen: :roll: :roll: