Beiträge von fulanke

    Hallo zusammen,

    Ich habe mit HBS drei Sync-Jobs angelegt, die jeweils die Shares vom QNAP auf einen neuen Synology DS224+ replizieren sollen (Ein-Wege-Sync).
    Für zwei der Shares funktioniert das problemlos, nur bei einem Share mit Dokumenten und Bildern bleibt der Job dann jeweils stundenlang bei 100% stehen und tut anscheinend nichts mehr (anfangs ist es mir einmal gelungen, den Job vollständig durchlaufen zu lassen).

    Ob wirklich alles übertragen wurde, ist nicht ersichtlich. In den Details steht Synchronisierung läuft - 100%, aber Dateinamen werden in diesem Status nicht mehr angezeigt.
    Verarbeitete Dateien 702,03 GB entspricht aber nicht dem tatsächlichen Wert von 757,25 GB (obwohl im Ziel 757,25 GB vorhanden sind).

    Ich habe mir das Zip mit den Logs heruntergeladen, sehe jetzt aber keinen eindeutigen Fehler. Ich habe den Job auch einmal gelöscht und komplett neu angelegt, der Fehler bleibt. Auch ein Reboot hat nichts gebracht.

    Das rra.log endet zum Beispiel bei 17:55 als eine kleine GIF-Datei aus einem Ordner übertragen werden sollte, danach kommt nichts mehr.

    Code
    [2024-01-16 17:55:21,883][ JobWorker][D][rsync_worker.py:job_local2remote_update_stat:690] : history: {'local_files_total': 194469, 'local_bytes_total': 813085654480, 'local_scan_status': 'done', 'local_files_processed': 156109, 'local_bytes_processed': 753735306736, 'bytes_uploaded': 288646893, 'local_files_unchanged': 36514, 'avg_upload_bytes_per_second': 22638, 'progress': 99, 'local_files_filtered': 0, 'local_files_skipped': 0, 'remaining_time': 1, 'local_files_remaining': 1846, 'local_bytes_remaining': 59164249, 'transferring': [{'path': 'FileServer/eBooks/Microsoft Excel/galileocomputing_excel_2007/excel_2007/bilder/EX03_467a.gif', 'filename': 'EX03_467a.gif', 'total_bytes': 35905, 'start_time': 1705424121, 'task_type': 'upload', 'progress': 0.0}]}
    [2024-01-16 17:55:25,925][ JobWorker][D][rsync_worker.py:job_local2remote_update_stat:690] : history: {'local_files_total': 194469, 'local_bytes_total': 813085654480, 'local_scan_status': 'done', 'local_files_processed': 157651, 'local_bytes_processed': 753794470985, 'bytes_uploaded': 288965581, 'local_files_unchanged': 36818, 'avg_upload_bytes_per_second': 22654, 'progress': 100, 'local_files_filtered': 0, 'local_files_skipped': 0, 'remaining_time': 0, 'local_files_remaining': 0, 'local_bytes_remaining': 0, 'transferring': []}

    Vorschläge zur weiteren Fehlersuche? Wenn sich der Job nicht beendet, ist es ja auch nicht möglich, per Schedule erneut zu starten.

    Ich schrieb ja, daß es keine generelle Regel gibt - es hängt von der Umgebung ab, vom QNAP-Modell etc. - denn verschiedene Firmware-Versionen setzen anscheinend auch unterschiedliche SAMBA-Versionen ein.


    Ich brauche für meinen TS 209 PRO 2 (aktuelle Firmware 3.3.0) mit 2 verschiedenen Windows 7 Rechnern auch keine Einstellungen zu ändern, um auf die Shares zuzugreifen. Was die User, die das Problem haben, nun genau nutzen, weiß ich nicht.


    An der Arbeit haben wir zum Teil recht alte Testmaschinen, die alte SAMBA-Versionen einsetzen. Hierfür ist die genannte Einstellung in der Security Policy nötig - den Registrywert hatte ich als Workaround genannt, ich selbst nutze kein Windows 7 Home. Auf jeden Fall muß der Wert den genannten Einstellungen in der Security Policy entsprechen - das ist auch in anderen Foren zu finden, wo Benutzer diese Einstellung getestet haben.


    Was die Werte genau bedeuten, steht ja im Technet:
    http://technet.microsoft.com/en-us/library/cc960646.aspx


    Sieht so aus, als ob es dann doch eher 1 statt 2 wäre....aber ich schrieb ja, ich nutze die Policy und nicht direkt die Registry :)

    *zensiert*


    Und für alle anderen, die noch an der Frage selbst Interesse haben: ein kurzer Test ergab, daß das Format des Benutzernamens bei richtigen Einstellungen (siehe voriger Beitrag) wie vermutet überhaupt keine Rolle spielt.


    Der Versuch, mit verschiedenen Schreibweisen wie RECHNER\BENUTZER zu hantieren, wird scheitern, weil die Authentifizierung generell scheitert. Das geht also am Thema vorbei.

    TrueFazer: möchtest du hier Haarspalterei betreiben? Ich schrieb bereits - auch ein NAS ist ein "Rechner" mit Hostname und wenn Benutzer/Passwort auf PC und NAS identisch sind, sollten beide Varianten funktionieren - dem ist technisch nichts hinzuzfügen.


    Davon abgesehen geht es um die Windows-Einstellungen, die ich nun bereits gepostet habe. Das hier beschriebene Verhalten ist sowieso eher ein Indiz dafür, daß die Authentifizierung aufgrund der Einstellungen geblockt wird...


    Hat einer der Herrschaften schon getestet?

    Zitat von "TrueFazer"

    Nicht Rechnername.


    <NASName>\<username> muss im Benutzer stehen.


    Ist das NAS kein Rechner mit eigenem Hostname? Wenn der Benutzer im NAS manuell angelegt wurde (also kein AD or LDAP konfiguriert), dann ist der "Rechnername" selbstverständlich der Hostname des NAS...wenn der gleiche Benutzer aber mit dem gleichen Passwort auf dem PC angelegt ist, sollte aber beides gehen.


    Aber das ist hier sowieso nicht das Thema, sage ich mal...einfach den nächsten Beitrag abwarten.


    EDIT:
    Jetzt zum Thema Samba und Windows 7:


    Man muß die Local Security Policy ändern und unter


    Security Settings - Local Policies - Security Options den Parameter


    Network security: LAN manager authentication level auf "Send LM&NTLM - use NTLMv2 session security if negot..."


    Das hat (vereinfacht ausgedrückt) was mit den verschärften Sicherheitseinstellungen unter Windows 7 zu tun, so daß vorsintflutliche SMB-Authentifizierung sonst nicht mehr durchgelassen wird. Das Ganze hängt aber auch mit der vorhandenen Systemkonfiguration, SAMBA-Version etc. zu tun, so daß das Problem kein generelles Problem ist.


    Wenn man Windows 7 Home hat, kann man die Einstellung nur in der Registry ändern, da es das SnapIn dort nicht gibt:


    DWORD value mit dem Namen LmCompatibilityLevel unter HKLM\System\CurrentControlSet\Control\Lsa einfügen und auf 2 setzen.


    Nach beiden Änderungen ist ein REBOOT nötig.


    Viel Spaß beim Testen.

    Du mußt im ersten Dialog "mit anderem Useraccount anmelden" anklicken (habe hier die englische Version - "Connect using different credentials"). Dann sollte ein Dialog mit User/Password ohne Domain aufgehen. Alternativ kann man auch noch diese Form probieren:


    RECHNERNAME\BENUTZER
    PASSWORT


    Außerdem gibt es bestimmte Windows-Einstellungen, die man gesetzt haben sollte, wenn man in einer AD-Umgebung mit Domänen arbeitet und gleichzeitig auf Linux-Büchsen per Samba zugreifen will...die habe ich irgendwo an der Arbeit gespeichert...Näheres könnte ich erst Dienstag sagen.

    Hi,


    Ich versuche es hier auch nochmal - vielleicht hat ja hier jemand eine Idee, wie man das lösen kann.


    In Kurzform: wie erreiche ich, daß die Icons für meine bereits existierenden Favoriten wieder angezeigt/neu aufgebaut werden, wenn diese auf einem NTFS-Share (USB-Stick) auf dem QNAP liegen?


    Ideen sind willkommen.


    ***
    Hi,


    Here is a strange issue which can be found in a lot of discussion forums on the internet (not specifically relating to the QNAP though) - I haven't found a solution to this after quite some research.


    System: Windows 7 Home 64 Bit English SP1, IE 9 (all updates installed), QNAP TS 209 PRO 2 (latest firmware), LAN network with multiple machines, netbook and multimedia devices.


    Situation: I want to move my Internet Explorer favorites to my USB stick connected to my QNAP TS 209 PRO 2, so that they are available on all machines. To do that, you change the 2 Favorites registry settings under HKCU\Software\Windows\CurrentVersion...


    Works fine but...the favorites' icons won't show up, even if you revisit each favorite. When you copy the favorites from your standard location (c:\users\user\favorites) to the QNAP share (\\qnap\USBDisk2\favorites), it tells you it will lose some properties if you continue (as if you're copying to a FAT drive or something). The USB stick however, is formatted as NTFS drive while Windows apparently doesn't see this as a NTFS drive (as it is a network location).


    I tried quite a lot to copy the favorites over while avoiding the data loss - creating an archive on the disk, copying the archive to the share and extracting it on the share, using robocopy with various options (you'll get a permission denied error 5 then) and what not. Permissions on the target share can be ruled out, I have opened the permissions for everyone for a test.


    Asides of that, the "export favorites" feature in IE 9 (9.0.8112.16421) seems to be broken - when it is asking you for the root folder for the export, it shows an empty window where you can't select anything. That means exporting and reimporting is not an option here either unless I can fix that IE issue.


    When I add a new favorite, it will store the favorite's icon. That means, the problem is only relevant for the existing favorites, not for new ones you're creating from now on.


    Questions:


    - Does anyone know a solution for this? I didn't find a way to force Windows to "rewrite" the favorites or rebuild the icon cache (deleting the Temporary Internet Files etc. doesn't change anything). It is not really practical to regenerate 1000+ favorites in subfolders that I created in over a decade.


    - Is this a general problem or is this some weird QNAP behavior? What is it doing when you copy special windows files to a QNAP share? I have the impression that it is changing some file properties as you copy the files which would also explain the permission errors using the robocopy command.


    - Would NFS be an option (?) and what clients would you require for Windows 7 Home? I know the Home Edition does not have any built-in NFS functionality.


    Any ideas left or am I ready to bury my head in the sand? A lot of work for some icons...
    ***