Beiträge von fbuebl

    Aloha -


    Mittlerweile hat sich das Problem in Luft aufgelöst. Ich kann das NAS wieder ganz normal über NFS mounten, ohne es dabei auf eine alte Version von NFS zu beschränken. Leider habe ich keine Ahnung, warum das zwei Wochen lang nicht ging - jetzt geht's jedenfalls wieder.


    Verneigung -
    - felix

    Ahoi -


    Mit der Beschränkung auf Version 2 von NFS ist nach einigen Tagen reibungsfreiem Betrieb doch ein Problem geschlüpft:


    NFS in der Version 2 kann nur Dateigrößen von maximal 2 GB.


    Bei meinem aktuellen Workaround muss ich also per FTP auf das NAS zugreifen, wenn es um eine grosse Datei geht.


    Verneigung -
    - felix

    guten abend -


    zu Salzstein:
    Bei mir sieht das Web Interface vom NAS genauso aus wie das zweite Photo (unter dem "Soll?" steht) von "deinem" Link http://forum.qnapclub.de/viewtopic.php?f=35&t=11461 - dort kann ich NFS aktivieren und habe es auch aktiviert.


    Michael schlägt vor:
    > kontrollieren was der router für eine IP vergeben hat.


    mein NAS sagt nach dem Befehl ifconfig:

    Code
    eth0      Link encap:Ethernet  HWaddr 00:08:9B:AD:12:F3            inet addr:192.168.1.5  Bcast:192.168.1.255  Mask:255.255.255.0


    > Das sollte nun eine .100 oder .101 am Ende sein.


    Warum? Monatelang hatte ich die .5 hinten, und das ging prima.


    und was sagt mein Client bei sudo mount -av?

    Code
    mount.nfs: timeout set for Wed Oct  6 20:22:36 2010mount.nfs: text-based options: 'soft,addr=192.168.1.5'mount.nfs: mount(2): Permission deniedmount.nfs: access denied by server while mounting 192.168.1.5:/share/HDA_DATA/Qmultimedia


    --


    Übrigens habe ich - nur zum Testen - auf dem NAS einen user derselben UID und GID wie auf dem Client. Daran scheitert es nicht.
    Und ausserdem: gibt es den Nutzer mit UID 65534 doch auf dem NAS: er heisst "guest".


    Auch das einschalten von FTP nach http://forum.qnap.com/viewtopic.php?t=8394 brachte: nüscht.


    Danke für eure Mithilfe!


    Verneigung -
    - felix


    achso -


    nach einem Reboot vom NAS führt exportfs auf dem NAS zu

    Code
    var/lib/nfs/etab:1: unknown keyword "mapping=identity"


    und ich habe immer noch nicht herausgefunden, wie ich das "mapping=identity" wegschlumpfen kann.
    wenn ich es von hand lösche, führt exportfs zu


    Code
    /share/HDA_DATA/Qmultimedia        192.168.1.*/share/HDA_DATA/Qdownload        192.168.1.*/share/HDA_DATA/Public        192.168.1.*


    knicks -
    - felix


    huch?!


    Besserung! Wenn ich vers=2 mit angebe, klappt das mounten!

    Code
    sudo mount -t nfs -o vers=2 192.168.1.5:/share/HDA_DATA/Qmultimedia /media/m


    Den Tip(p) fand ich hier: http://forum.qnap.com/viewtopic.php?f=35&t=14934


    Misteriös: wenn ich das "-o vers=2" weglasse, kommt immer noch die Permission Denied Meldung, aber dennoch: klappt das mount - ich kann dann auf die Files zugreifen. Das ging die letzten Tage nicht mehr... Liegt es daran, dass ich jetzt mein exportfs auf dem NAS jetzt so aussieht?


    Code
    exportfs    /share/HDA_DATA/Qmultimedia        192.168.1.7/share/HDA_DATA/Qmultimedia        192.168.1.8


    In irgendeinem Forum war empfohlen worden, hier doch nicht den Wildcard 192.168.1.* zu verwenden...


    Platon wusste: ich weiß, daß ich nichts weiß,


    Ich habe nun also auf dem client in der fstab die option nfsvers=2 eingefügt:

    Code
    192.168.1.5:/share/HDA_DATA/Qmultimedia /media/m nfs soft,rw,auto,nfsvers=2 0 0


    und: das mounten klappt wieder schön automatisch.


    Der Weltfrieden wird nicht einmal dadurch gestört, dass auf dem NAS immer noch der Befehl "exportfs" zu

    Code
    exportfs: /var/lib/nfs/etab:1: unknown keyword "mapping=identity"


    führt.... egal, erstmal scheint der Fall gelöst. Ich melde mich in ein paar Tagen nochmal, ob das eine stabile Lösung war.


    Die Files werden nun übrigens auf dem NAS mit dem Nutzer angelegt, der diesselbe UID hat wie "ich" auf dem Client. Früher: wurde auf dem Admin daraus ein Nutzer, der eine andere UID, aber denselben Namen hat wie der Nutzer auf dem Client. Aber egal, hauptsache es geht.

    ahoi -


    Ein gutes Jahr lang konnte ich per NFS auf meine TS 109 pro II zugreifen.
    Seid Samstag aber kommt beim mount-versuch:


    Code
    mount.nfs: mount(2): Permission deniedmount.nfs: access denied by server while mounting 192.168.1.5:/share/HDA_DATA/Qmultimedia


    Einen tollen Workaround hatte ich am Sonntag gefunden: ich gehe per ssh auf das NAS und bitte es um

    Code
    ipkg install -force-reinstall nfs-utils


    ...und siehe da: mounten geht wieder bis zum nächsten Reboot vom NAS.


    Ich musste also beim Startup vom NAS jedesmal die nfs-utils neu installieren - eine Traumlösung war das nicht.



    Nach dem reinstall der nfs-utils sagt exportfs auf dem NAS:

    Code
    /share/HDA_DATA/Qmultimedia        192.168.1.*/share/HDA_DATA/Qdownload        192.168.1.*/share/HDA_DATA/Public        192.168.1.*



    aaaber nach dem Neustart vom NAS sagt sein exportfs

    Code
    exportfs: /var/lib/nfs/etab:1: unknown keyword "mapping=identity"


    und leider: wird dieses etab file bei jedem Neustart neu generiert - es nützt als nix, wenn ich das "mapping=identity" von Hand rauslösche.


    --


    Achja: was geschah am Samstag? Ich kaufte einen neuen Router und baute ihn ein. Dabei gab es fuer einige Minuten den illegalen Zustand, dass der Router dem NAS die Adresse 192.168.1xy.22 geben wollte, aber das NAS eine feste IP von 192.168.1.5 haben wollte. Seitdem: ist irgend ein Wurm drin.


    --


    Am Sonntag habe ich dem NAS die neueste Firmware 3.3.0 spendiert (vorher war 3.1.0) - brachte aber keine Linderung.


    ---


    Seid Montag: klappt auch der reinstal nfs-utils trick nicht mehr - die permission bleibt denied.


    Habe ein auf Empfehlung von http://forum.qnap.com/viewtopic.php?f=35&t=32147 ein Downgrade auf Firmware 3.2.0 eingespielt, brachte aber nix.


    achja: exportfs -v auf dem NAS liefert

    Code
    /share/HDA_DATA/Qmultimedia
            192.168.1.*(rw,async,wdelay,no_root_squash,anonuid=65534,anongid=65534)
    /share/HDA_DATA/Qdownload
            192.168.1.*(rw,async,wdelay,no_root_squash,anonuid=65534,anongid=65534)
    /share/HDA_DATA/Public
            192.168.1.*(ro,async,wdelay,no_root_squash,anonuid=65534,anongid=65534)


    Die uid 65534 gehört typischerweise zum user "nobody". Den gibt es allerdings nicht auf meinem NAS. Ist das das Problem?


    mit ratloser Verneigung -
    - felix

    ahoi christian -

    nur zur klaerung: das kaltstromgeraetekabel hat zwei stecker:


    a) in die strom steckdose "vom baumarkt"
    b) in das netzteil von NMR (mitgeliefert von qnap)


    ich hatte den stecker auf seite b) nur halbherzig eingesteckt.


    verneigung -
    - felix

    ich bin verbluefft, wie schnell hier geholfen wird - danke an christian und achim!


    nun habe ich nochmal die TS109 aufgeschraubt und das von mir "zur isolierung" unter
    die festplatte gelegte papier rausgenommen und siehe da: es geht prima ohne das papier.
    nach ein bisschen gruebeln und probieren fand ich auch heraus, was wirklich der grund fuer
    den "kurzschluss" war: von der strom-steckdose geht ein kaltstromgeraetekabel
    zum netzteil. wenn dessen stecker nicht fest im netzteil steckt sondern nur wackelig,
    dann bekommt die TS109 zu wenig aeh strom und bootet nicht.


    ich war also anfangs nur zu schlampig beim stromanschluss und habe mir dann
    unnoetige sorgen ueber meinen einbau der festplatte gemacht. vielleicht gewinne
    ich mit der aktion ja einen preis als qnap-dussel des monats?

    ahoi -


    dieses problem war gar keines: ich hatte nur das netzteil wackelig angeschlossen.
    und dann ergaben sich diese symptome und meine falschen vermutungen:


    problem:


    habe gerade meine TS 109pro II geholt, die festplatte WD RE2-GP WD1000FYPS eingeschraubt
    und eingeschaltet. zwei der LEDs blinkten ganz kurz auf, und dann schweigen im walde (kein bootvorgang oder aehnliches)
    auch mehrmaliges druecken des powerknopfes bewirkt dann solange nichts, bis man den netzstecker aus- und
    wieder einsteckt. dann kommt man wieder zum kurzen LED blinker.



    loesung:


    schon beim ersten einbau der festplatte sah es fuer mich so aus, als ob die platine der festplatte direkten kontakt
    mit dem blech in der 109 hat. nach obigem problem baute ich also die festplatte aus und startete
    erstmal ohne platte - und das klappte. dann schnitt ich ein papierblatt in groesse der festplatte aus und
    legte es auf das blech und danach die festplatte auf das papier und baute sie ein. und siehe da: nun
    laeuft es.


    uebrigens: meine festplatte steht in der kompatibilätsliste http://www.qnap.com/de/pro_compatibility.asp



    fragen:


    * ist mein TS109pro II ein garantiefall? fehlen da irgendwo 2 milimeter im gehaeuse - sollte ich es umtauschen?


    * welches material sollte ich als isolier-schicht verwenden? plastik koennte schmelzen... ich nehme karton, oder?


    * bin ich der einzige, dem sowas passiert? oder bin ich zu dusselig zur forensuche?



    danke -
    - felix