Hallo
Ich habe auf ein 459 Pro II (FW 4.02) die TV station installiert, anschließend den Eye TV DTT (steht auf der Kompatibilitätsliste, da bin ich bei QNAP vorsichtig geworden!!) angeschlossen (an diversen USB-Steckern), leider kommt im Menu der TV Station nur: "kein Tuner erkannt", auch nicht nach einem Reboot der TS: Was ist zu tun??? 
Gruß J.
Gelöst: Router reboot tut gut....:-)
Gruß J.
Ja, die Vermutung mit dem DNS hatte ich auch schon, denn es werden auch die "QNAP-Neuigkeiten" auf der Startseite nicht geladen...
Allerdings habe ich den "DNS-Server" von automatisch beziehen bei der Installation auf die IP meines Routers geändert (nein, kein Tippfehler). Sollte zwar richtig sein, aber das würde ich jetzt ja auch gerne mal rückgängig machen, allerdings läßt die QNAP das irgendwie nicht zu.....der Haken bleibt ausgegraut....
Das "Port-Trunking" habe ich jetzt mal ausgeschaltet, bringt aber auch nichts...
Noch eine Idee, außer "werksreset"?? Bitte Info, danke
Gruß JK
Schön, hier leider nicht, der Rest der 459 Pro (gerade neu) läuft bisher ohne Fehler: Was kann man denn falsch machen, damit diese Meldung nach dem Klick auf "QPKG abrufen" kommt? : "Leider stehen keine QPKG-Daten zur Verfügung". Bei meiner TS 239 ging das bisher ohne jedes Problem....??? 
Und auf der geht es auch jetzt ohne jedes Problem...
Sie steht direkt neben dran, und hängt am selben Router....muß ich Ports freigeben???
Gruß JK
Hallo
Ich habe seit heute das Gleiche Problem: Es eerscheine keien QPKG's: Hat der Server wieder Probleme??
Oder mache ich was falsch?
Gruß J.
Salut
Noch eine Info als Hiweis für die Experten: Ich habe gesehen, dass Winscp ja auch einen Befehl zum synchronisieren enthält. Den habe ich mal benutzt.
Da kommt dann nach kurzer Zeit als Fehlermeldung:
Kann Pfad für /share/external/sdy5/Public/Für J+K nicht anlegen
Datei oder Verzeichnis nicht gefunden.
Fehlernummer: 2
Fehlermeldung vom entfernten Rechner : No such file
Anforderungsnummer: 14
(Dabei wird der Umlaut so angezeigt: für J+K)
Kann es sein, dass der sync-Befehl Probleme mit Umlauten im Dateinamen oder in der Pfadangabe jhat und dabei denn abbricht???
Salut
Die Idee ist gut, leider kenne ich mich nicht gut mit der Kommandozeile aus (ich kann "nachmachen")
Wenn ich mit Winscp in die Platte reingucke, heißt der Pfad z.B. : /share/external/sdy5/Public (der Pfad zur externe eSATA-Platte scheint nur in "Verweis" zu sein).
Würde der Befehl dann lauten: rsync -av --stats --progress /share/external/sdy5/Public ???
Bitte kurze Rückinfo da ich "nicht-linuxer" bin, danke
Gruß JK
Salut
Ich habe es auf synchronisieren stehen, allerdings sollte es sich hier dann doch um ein kopieren handeln, denn es ist ja noch nicht ein Vorgang des synchronisierens erfolgreich abgeschlossen worden.
Ich habe die Partition im Moment auf NTFS formatiert, hatte es aber auch schon mit EXT4 probiert: selber Mißerfolg. Die Firmware ist die neueste offiziell verfügbare: Aktuelle Firmwareversion: 3.2.6 Build 0423T, aber Achtung: ich habe eine TS239 Pro, das Problem ist nur das Gleich wie beim Threaderöffner; allerdings sind in der Tat mehrere Dateien > 4 Gb. Ist das für NTFS ein Problem??
Gruß J.
Salut
Also, ich denke nicht, dass die Platten da frisch gebootet waren, weiß es aber nicht mehr...
Weil sich dass Problem so schön reproduzieren läßt (grrrr...), habe ich es eben "mal kurz" wiederholt: Backup angestellt, es dauert keine 2 Minuten, da kam die Abbruchmeldung und dann dieses dmesg:
/root$
dmesg
kjournald starting. Commit interval 5 seconds
EXT3 FS on md9, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
md: bind<sda2>
md: md2: raid array is not clean -- starting background reconstruction
raid1: raid set md2 active with 1 out of 1 mirrors
md2: unknown partition table
Adding 530040k swap on /dev/md2. Priority:-1 extents:1 across:530040k
md: bind<sdb2>
RAID1 conf printout:
--- wd:1 rd:2
disk 0, wo:0, o:1, dev:sda2
disk 1, wo:1, o:1, dev:sdb2
md: recovery of RAID array md2
md: minimum _guaranteed_ speed: 5000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
md: Recovering started: md2
md: using 128k window, over a total of 530048 blocks.
active port 0 :139
active port 1 :445
active port 2 :20
md: md2: recovery done.
md: Recovering done: md2, degraded=1
RAID1 conf printout:
--- wd:2 rd:2
disk 0, wo:0, o:1, dev:sda2
disk 1, wo:0, o:1, dev:sdb2
md: md0 still in use.
md: bind<sdb3>
md: bind<sda3>
raid1: raid set md0 active with 2 out of 2 mirrors
md0: bitmap initialized from disk: read 15/15 pages, set 158 bits
created bitmap (233 pages) for device md0
md0: unknown partition table
EXT4-fs (md0): barriers enabled
kjournald2 starting: pid 2313, dev md0:8, commit interval 5 seconds
EXT4-fs (md0): internal journal on md0:8
EXT4-fs: file extents enabled
EXT4-fs: mballoc enabled
EXT4-fs (md0): mounted filesystem with ordered data mode
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
active port 0 :139
active port 1 :445
active port 2 :20
warning: `proftpd' uses 32-bit capabilities (legacy support in use)
TARGET_CORE[0]: Loading Generic Kernel Storage Engine: v3.1.0 on Linux/i686 on 2.6.30.6
TARGET_CORE[0]: Initialized ConfigFS Fabric Infrastructure: v2.0.0 on Linux/i686 on 2.6.30.6
SE_PC[0] - Registered Plugin Class: TRANSPORT
PLUGIN_TRANSPORT[1] - pscsi registered
PLUGIN_TRANSPORT[2] - stgt registered
CORE_STGT[0]: Bus Initalization complete
PLUGIN_TRANSPORT[4] - iblock registered
PLUGIN_TRANSPORT[5] - rd_dr registered
PLUGIN_TRANSPORT[6] - rd_mcp registered
PLUGIN_TRANSPORT[7] - fileio registered
SE_PC[1] - Registered Plugin Class: OBJ
PLUGIN_OBJ[1] - dev registered
Initiate iscsi target log successfully.
Linux-iSCSI.org iSCSI Target Core Stack v3.1.0 on Linux/i686 on 2.6.30.6
<<<<<<<<<<<<<<<<<<<<<< BEGIN FABRIC API >>>>>>>>>>>>>>>>>>>>>>
Initialized struct target_fabric_configfs: da8f1c00 for iscsi
<<<<<<<<<<<<<<<<<<<<<< END FABRIC API >>>>>>>>>>>>>>>>>>>>>>
LIO_TARGET[0] - Set fabric -> lio_target_fabric_configfs
iscsi_allocate_thread_sets:195: ***OPS*** Spawned 4 thread set(s) (8 total threads).
TARGET_CORE[iSCSI]: Allocated Discovery se_portal_group_t for endpoint: None, Portal Tag: 1
CORE[0] - Allocated Discovery TPG
Loading Complete.
iscsi_log_rcv_msg: get log pid = 4588.
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
rule type=2, num=0
Loading iSCSI transport class v2.0-871.
iscsi: registered transport (tcp)
CE: hpet increasing min_delta_ns to 15000 nsec
UDP: bad checksum. From 61.9.94.65:1343 to 192.168.1.80:59367 ulen 111
[0 3] Detect fake interrupts.
QNAP: Got fake interrupts.(cnt=0)
ENABLE_WRITE_CACHE (current: enabled).
scsi 9:0:0:0: Direct-Access Seagate ST31000528AS CC44 PQ: 0 ANSI: 3
Check proc_name[mvSata].
Check proc_name[mvSata].
sd 9:0:0:0: [sdz] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB)
sd 9:0:0:0: Attached scsi generic sg25 type 0
sd 9:0:0:0: [sdz] Write Protect is off
sd 9:0:0:0: [sdz] Mode Sense: 23 00 10 00
sd 9:0:0:0: [sdz] Write cache: enabled, read cache: enabled, supports DPO and FUA
sdz: sdz1 < sdz5 >
sd 9:0:0:0: [sdz] Attached SCSI disk
active port 0 :139
active port 1 :445
active port 2 :20
fs/splice.c: 1282: do_splice_from_socket: kernel_recvmsg error,estimate 32768,real 6791
[0 3] Detect fake interrupts.
[0 3] Fake interrupts detection finished.
sd 9:0:0:0: [sdz] Synchronizing SCSI cache
sd 9:0:0:0: [sdz] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
active port 0 :139
active port 1 :445
active port 2 :20
ENABLE_WRITE_CACHE (current: enabled).
scsi 8:0:0:0: Direct-Access Seagate ST31000528AS CC44 PQ: 0 ANSI: 3
Check proc_name[mvSata].
Check proc_name[mvSata].
sd 8:0:0:0: Attached scsi generic sg24 type 0
sd 8:0:0:0: [sdy] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB)
Wake up disk 2 immediately.
sd 8:0:0:0: [sdy] Write Protect is off
sd 8:0:0:0: [sdy] Mode Sense: 23 00 10 00
sd 8:0:0:0: [sdy] Write cache: enabled, read cache: enabled, supports DPO and FUA
sdy: sdy1 < sdy5 >
sd 8:0:0:0: [sdy] Attached SCSI disk
NOHZ: local_softirq_pending 80
fs/splice.c: 1282: do_splice_from_socket: kernel_recvmsg error,estimate 32768,real 32304
iscsi target log cleanup successfully.
iscsi_deallocate_thread_sets:235: ***OPS*** Stopped 4 thread set(s) (8 total threads).
TARGET_CORE[Discovery]: Deallocating iSCSI se_portal_group_t for endpoint: <NULL> Portal Tag 1
<<<<<<<<<<<<<<<<<<<<<< BEGIN FABRIC API >>>>>>>>>>>>>>>>>>>>>>
Target_Core_ConfigFS: DEREGISTER -> Releasing tf: iscsi
<<<<<<<<<<<<<<<<<<<<<< END FABRIC API >>>>>>>>>>>>>>>>>>>>>>
LIO_TARGET[0] - Cleared lio_target_fabric_configfs
Unloading Complete.
TARGET_CORE[0]: Released ConfigFS Fabric Infrastructure
CORE_STGT[0]: Bus release complete
ext4_put_super(ee8aae00)
EXT4-fs: mballoc: 7833 blocks 7833 reqs (0 success)
EXT4-fs: mballoc: 8011 extents scanned, 2915 goal hits, 4905 2^N hits, 0 breaks, 0 lost
EXT4-fs: mballoc: 7513 generated and it took 178329972
EXT4-fs: mballoc: 1919820 preallocated, 398947 discarded
active port 0 :139
active port 1 :445
active port 2 :20
TARGET_CORE[0]: Loading Generic Kernel Storage Engine: v3.1.0 on Linux/i686 on 2.6.30.6
TARGET_CORE[0]: Initialized ConfigFS Fabric Infrastructure: v2.0.0 on Linux/i686 on 2.6.30.6
SE_PC[0] - Registered Plugin Class: TRANSPORT
PLUGIN_TRANSPORT[1] - pscsi registered
PLUGIN_TRANSPORT[2] - stgt registered
CORE_STGT[0]: Bus Initalization complete
PLUGIN_TRANSPORT[4] - iblock registered
PLUGIN_TRANSPORT[5] - rd_dr registered
PLUGIN_TRANSPORT[6] - rd_mcp registered
PLUGIN_TRANSPORT[7] - fileio registered
SE_PC[1] - Registered Plugin Class: OBJ
PLUGIN_OBJ[1] - dev registered
Initiate iscsi target log successfully.
Linux-iSCSI.org iSCSI Target Core Stack v3.1.0 on Linux/i686 on 2.6.30.6
<<<<<<<<<<<<<<<<<<<<<< BEGIN FABRIC API >>>>>>>>>>>>>>>>>>>>>>
Initialized struct target_fabric_configfs: da5c9400 for iscsi
<<<<<<<<<<<<<<<<<<<<<< END FABRIC API >>>>>>>>>>>>>>>>>>>>>>
LIO_TARGET[0] - Set fabric -> lio_target_fabric_configfs
iscsi_allocate_thread_sets:195: ***OPS*** Spawned 4 thread set(s) (8 total threads).
TARGET_CORE[iSCSI]: Allocated Discovery se_portal_group_t for endpoint: None, Portal Tag: 1
CORE[0] - Allocated Discovery TPG
Loading Complete.
iscsi_log_rcv_msg: get log pid = 24917.
EXT4-fs (md0): barriers enabled
kjournald2 starting: pid 28150, dev md0:8, commit interval 5 seconds
EXT4-fs (md0): internal journal on md0:8
EXT4-fs: file extents enabled
EXT4-fs: mballoc enabled
EXT4-fs (md0): mounted filesystem with ordered data modeHilft das weiter???
Gruß JK
Hallo
Ich habe dasselbe Problem, wenn auch auf einer TS239 (mit aktueller FW), wie auch schon in anderem Thread geschrieben, allerdings bisher keine Lösung für dieses Problem. Ich habe mich gerade per Winscp verbunden auf auf das von linuxnutzer vorgeschlagene dmesg kam folgende Antwort: Versteht sie vielleicht hier jemand??
/root$ dmesg
2-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.1: setting latency timer to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000b880
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: setting latency timer to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000b800
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.3: setting latency timer to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000b480
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb: create proc systemp successfully
usb: create proc systemp successfully
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with writeback data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with writeback data mode.
md: md9 stopped.
md: bind<sdb1>
md: bind<sda1>
raid1: raid set md9 active with 2 out of 2 mirrors
md9: bitmap initialized from disk: read 5/5 pages, set 22 bits
created bitmap (65 pages) for device md9
md9: unknown partition table
kjournald starting. Commit interval 5 seconds
EXT3 FS on md9, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
md: md13 stopped.
md: bind<sdb4>
md: bind<sda4>
raid1: raid set md13 active with 2 out of 2 mirrors
md13: bitmap initialized from disk: read 4/4 pages, set 0 bits
created bitmap (57 pages) for device md13
md13: unknown partition table
kjournald starting. Commit interval 5 seconds
EXT3 FS on md9, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md9, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md13, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
ICH7/ICH9R rtc control driver.
iTCO_vendor_support: vendor-support=0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.05
iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, TCOBASE=0x0860)
iTCO_wdt: initialized. heartbeat=120 sec (nowayout=0)
usbcore: registered new interface driver usblp
ufsd: module license 'Commercial product' taints kernel.
Disabling lock debugging due to kernel taint
ufsd: driver loaded at f8354000 built on Apr 23 2010 13:56:20
UFSD version 7.07 (Sep 25 2009, 17:23:02)
NTFS read/write support included
$Id: ufsdvfs.c,v 1.1.1.1 2009/10/07 02:37:25 penny Exp $ (LBD=ON)
kjournald starting. Commit interval 5 seconds
EXT3 FS on md9, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
md: bind<sda2>
md: md2: raid array is not clean -- starting background reconstruction
raid1: raid set md2 active with 1 out of 1 mirrors
md2: unknown partition table
Adding 530040k swap on /dev/md2. Priority:-1 extents:1 across:530040k
md: bind<sdb2>
RAID1 conf printout:
--- wd:1 rd:2
disk 0, wo:0, o:1, dev:sda2
disk 1, wo:1, o:1, dev:sdb2
md: recovery of RAID array md2
md: minimum _guaranteed_ speed: 5000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
md: Recovering started: md2
md: using 128k window, over a total of 530048 blocks.
active port 0 :139
active port 1 :445
active port 2 :20
md: md2: recovery done.
md: Recovering done: md2, degraded=1
RAID1 conf printout:
--- wd:2 rd:2
disk 0, wo:0, o:1, dev:sda2
disk 1, wo:0, o:1, dev:sdb2
md: md0 still in use.
md: bind<sdb3>
md: bind<sda3>
raid1: raid set md0 active with 2 out of 2 mirrors
md0: bitmap initialized from disk: read 15/15 pages, set 158 bits
created bitmap (233 pages) for device md0
md0: unknown partition table
EXT4-fs (md0): barriers enabled
kjournald2 starting: pid 2313, dev md0:8, commit interval 5 seconds
EXT4-fs (md0): internal journal on md0:8
EXT4-fs: file extents enabled
EXT4-fs: mballoc enabled
EXT4-fs (md0): mounted filesystem with ordered data mode
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
active port 0 :139
active port 1 :445
active port 2 :20
warning: `proftpd' uses 32-bit capabilities (legacy support in use)
TARGET_CORE[0]: Loading Generic Kernel Storage Engine: v3.1.0 on Linux/i686 on 2.6.30.6
TARGET_CORE[0]: Initialized ConfigFS Fabric Infrastructure: v2.0.0 on Linux/i686 on 2.6.30.6
SE_PC[0] - Registered Plugin Class: TRANSPORT
PLUGIN_TRANSPORT[1] - pscsi registered
PLUGIN_TRANSPORT[2] - stgt registered
CORE_STGT[0]: Bus Initalization complete
PLUGIN_TRANSPORT[4] - iblock registered
PLUGIN_TRANSPORT[5] - rd_dr registered
PLUGIN_TRANSPORT[6] - rd_mcp registered
PLUGIN_TRANSPORT[7] - fileio registered
SE_PC[1] - Registered Plugin Class: OBJ
PLUGIN_OBJ[1] - dev registered
Initiate iscsi target log successfully.
Linux-iSCSI.org iSCSI Target Core Stack v3.1.0 on Linux/i686 on 2.6.30.6
<<<<<<<<<<<<<<<<<<<<<< BEGIN FABRIC API >>>>>>>>>>>>>>>>>>>>>>
Initialized struct target_fabric_configfs: da8f1c00 for iscsi
<<<<<<<<<<<<<<<<<<<<<< END FABRIC API >>>>>>>>>>>>>>>>>>>>>>
LIO_TARGET[0] - Set fabric -> lio_target_fabric_configfs
iscsi_allocate_thread_sets:195: ***OPS*** Spawned 4 thread set(s) (8 total threads).
TARGET_CORE[iSCSI]: Allocated Discovery se_portal_group_t for endpoint: None, Portal Tag: 1
CORE[0] - Allocated Discovery TPG
Loading Complete.
iscsi_log_rcv_msg: get log pid = 4588.
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:0 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
Set Adpater:port=0:1 standby to 242 (3600 secs).
rule type=2, num=0
Loading iSCSI transport class v2.0-871.
iscsi: registered transport (tcp)
CE: hpet increasing min_delta_ns to 15000 nsec
UDP: bad checksum. From 61.9.94.65:1343 to 192.168.1.80:59367 ulen 111
[0 3] Detect fake interrupts.
QNAP: Got fake interrupts.(cnt=0)
ENABLE_WRITE_CACHE (current: enabled).
scsi 9:0:0:0: Direct-Access Seagate ST31000528AS CC44 PQ: 0 ANSI: 3
Check proc_name[mvSata].
Check proc_name[mvSata].
sd 9:0:0:0: [sdz] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB)
sd 9:0:0:0: Attached scsi generic sg25 type 0
sd 9:0:0:0: [sdz] Write Protect is off
sd 9:0:0:0: [sdz] Mode Sense: 23 00 10 00
sd 9:0:0:0: [sdz] Write cache: enabled, read cache: enabled, supports DPO and FUA
sdz: sdz1 < sdz5 >
sd 9:0:0:0: [sdz] Attached SCSI disk
active port 0 :139
active port 1 :445
active port 2 :20Wäre toll, wenn endlich mal jemand eine Lösung für dieses Problem hätte... 
Gruß J.
Hallo
Wollte nur kurz sagen, dass ich von eben diesem Problem schon am 27.1.d.J. berichtete, keine Änderung am Zustand bisher, weder der Anschluß als eSATA der externen Platte, noch das Update auf die neueste FW hat bisher geholfen:
Ich zitiere: "Aktuelle Datensicherungsstatus: Bereit
Terminieren
Letzte Datensicherungszeit: 2010/03/07 21:10:01 ~ 2010/03/07 21:10:21
Letztes Datensicherungsergebnis: Datensicherung fehlgeschlagen "
Schade, ich hatte soviel Hoffnung auf die aktuelle FW gesetzt, noch dazu wo die Jungs bei QNAP das Problem ja scheinbar gelöst haben wollten: s. unter Major bug fixing:
"[Major Bug Fixing]
- Fixed stability issue with MPIO
- Fixed failed Remote Replication jobs and removed the progress indicator in Remote Replication
- Fixed rsync segmentation fault error in some cases
- Fixed failed synchronized backup jobs when backing up to external drives"
Da kann ich nur sagen: Das war wohl nichts....
Gruß an die Gemeinde, J.
Hallo
Schön für Dich 
.. ich Habe auf die neuste FW upgegradet, hat nicht geholfen...und das mit dem rsync finde ich als Nicht-Linuxer zu gewagt, zumal es ja nicht permanent abhilfe schafft.
Aber immerhin scheint QNAP sich des Problems ja bewußt zu sein, vielleicht komt dann ja bald eine bessere FW :shock:
Gruß JK
Hallo
Nur der Vollständigkeithalber: Meine FW ist die 3.2.0 Build 1212T und damit noch älter... Hat denn niemand sonst das Problem??
Gruß, J.
Hallo
Sorry, aber was meinst du mit "zugreifen" über Samba?? Bin kein IT-Experte..., ich konnte die Platte am vorderen Anschluß mittleweile neu formatieren (NTFS) und nun läuft geade ein Backup der Daten; scheinbar mag die TS eine unter Windows in NTFS formatierte Platte nicht, kann das sein, dass sie nur ihr eigenes NTFS erkennt?
Leider kommt beim Backup nach kurzer Zeit die Meldung :" Letzte Datensicherungszeit: 2010/01/31 09:13:37 ~ 2010/01/31 09:14:07
Letztes Datensicherungsergebnis: Datensicherung fehlgeschlagen "
Hat irgendeiner noch irgendeine Idee?
Gruß J.
Hallo
Danke für den HInweis; an dem vorderen Anschluß wird die Platte in der Tat erkannt, aber wenn ich dann versuche, Verzeichnisinhalte rüberzukopieren als Backup, kommt leider dies hier: "[External Drive] Copy out: Copying to [USBDisk1] from share(Public;Qmultimedia;Unsere xxxx) failed." 
Dazu noch eine Idee?
Gruß J.
Hallo
Zu Backup-Zwecken habe ich per Sharkoon-Quickport versucht, eine unter Windows 7 Pro auf NTFS, formatierte, nicht-leere 750 GB Seagate Festplatte (Barracuda ES.2, ST31000340AS) per USB an meine TS 239 Pro anzuschließen (Anschlüsse auf der Rückseite des Gehäuses). Leider kommt da in "Systemereignisprotokolle" nur der Eintrag:
" 2010-01-27 3163 19:55:05 System 127.0.0.1 localhost Number of USB devices connected is over limitation. " und die Platte wird unter "Externes Gerät - externer Speicher" nicht erkannt. Mit der Fehlermeldung kann ich nichts anfagen, denn es ist das einzige, extern an die TS angeschlossene Gerät, so gesehen können es nicht "zuviel USB-Devices" sein.Was kann das Problem sein? Unter Windows wird die Platte einwandfrei erkannt, neu gebootet habe ich die TS auch schon.... Für jede Idee dankbar, Gruß J.
Hallo
Jaja, neu gestartet habe ich den Router sowie den Vista-Rechner mehrfach, aber das alles half nicht: Was geholfen hat, war den Router Speedtouch 546 auf Werkseinstellungen zurückzusetzen: macht zwar etwas Arbeit anschließend, aber mit der TS-239 war hinterher alles ein Kinderspiel: so wie im Handbuch beschrieben.
Ich weiß natürlich nicht, woran sich der Router gestoßen hat, aber jetzt funzt es! Danke für Eure Unterstützung!!!! :thumb:
Salut
Nein, das ist meines Erachtens nicht verwunderlich: Wie ich oben schrieb (Der Router hat zur Verfügung: 192.168.1.1 - 100 (Gateway 192.168.1.254) und 192.168.10.1 - 100 (Gateway 192.168.10.1) beide mit der Subnetzmaske 255.255.255.0. Damit funktionieren alle meine Netzgeräte..) , sind für den Router beide Adressbereiche "zulässig" und er weist die erste zur Verfügung stehende IP dem NAS zu und das sollte eine Adresse aus 192.168.1.xxx sein, oder?
Im Anhang ein Screenshot mit den Subnetzeinstellungen meines Heimnetzes: beide IP-Bereiche haben des Subnetz 24 (= 255.255.255.0, wenn ich das richtig erinnere)
Meint Ihr es macht Sinn, auf das 192.168.10.xxx Netz zu verzichten? Dies ist nur noch "historisch" bedingt da, und wird nicht mehr wirklich benötigt, war bisher nur zu faul, es zu ändern/abzuschaffen)
Die Frage, die ich mir stelle ist ja auch: Warum zieht sich das NAS nicht die xxx.xxx.xxx.x80, wenn ich es ihr doch fest vorgebe (und die Adresse frei ist)
Hallo
Es geht um eine 239 Pro, ich habe nur 1 Netzwerkkabel angeschlossen (habe kein Router, der "port trunking" kann), laut Eintrag im Router ist die "feste" IP 192.168.10.80 frei (die alte IP der TS239), aber wenn ich die IP per DHCP zuweisen lassen, erhält die QNAP z.b. die 192.168.1.5, die laut Router ebenfalls frei sein sollte.
Doppelte IP's möchte ich nahezu ausschliessen, s. Anhang
Gerade eben sehe ich, dass das Gerät mit der MAC-Adresse der TS die IP xxx.80 bekommen hat...aber leider weiterhin nicht ansprechbar ist,
Wie geht "LEASE löschen??",
Hallo
Naja, es ging ja vorher mit derselben IP: Der Router hat zur Verfügung: 192.168.1.1 - 100 (Gateway 192.168.1.254) und 192.168.10.1 - 100 (Gateway 192.168.10.1) beide mit der Subnetzmaske 255.255.255.0. Damit funktionieren alle meine Netzgeräte..
Das merkwürdige ist ja, dass der Router immer die 192.168.1.5 per DHCP vergibt (ist im Prinzip frei), auf dieser IP kann ich sie (hinter dem Router) aber weder ansprechen, noch anpingen, noch findet der Finder sie...
Direkt angeschlossen am Laptop kann ich über die 169.xxx.xx.xxx (Standard IP von QNAP) auf sie zugreifen, diese wird natürlich in meinem Heimnetz nicht geroutet...