NFS Freigabe zickt nach Migration

    Hallo zusammen,

    es ist wieder soweit, ich bin zwar mit meinen Latein noch nicht am ende aber vielleicht hat ja hier jemand den richtigen Tip zur Ergreifung des Fehlers.


    Vorgeschichte:

    Ein Qnap TS-879U-RP mit 4.2.5 FW ist ausgefallen und auch mit gezogenen Platten nicht mehr angegangen. Halb so wild, es stand ja noch ein TS-871U-RP bereit auf den migriert werden sollte. Da auf dem 871er bereits 4.3.6 FW installiert wurde, habe ich die Platten migriert und die aktuelle FW nochmal mit Qfinder installiert. Nun ging so einiges nicht mehr wie Externe Rsync Backup Jobs, LACP Netzwerkschnittstellen config etc. habe ich aber alles schon gefixt, bis auf einen NFS Fehler...


    Problem:

    Es gibt eine NFS Freigabe welche seit der Migration ein seltsames Verhalten aufweist, welchen ich bisher nicht auf die Schliche gekommen bin.

    Die Freigabe an sich läuft, d.h. Clients haben eine statische Config welche nach wie vor funktioniert, nur kommt es jetzt sporadisch vor das $Random Ordner nicht angezeigt werden für eine Dauer von ca.5-10min, falls die Ordner die verschwinden in Zugriff waren, ist dieser innerhalb der genannten Zeit auch nicht mehr gegeben. Dieser Fehler tritt geschätzt alle 1-2Std. auf, sobald ich genauere Zeiten habe bzw. periodisches Verhalten erkennen kann würde ich das nachreichen - habe ich bisher jedoch nicht.


    Troubleshooting:

    Wo ist den nun der Fehler? -> Ausschlussprinzip:

    • Clients: (Mac OS Mojave) Es wurden keine Änderungen vorgenommen, weshalb ich diese erstmals als Fehlerquelle ausschließe
    • Server: NFS Settings sind unverändert, FW wurde von 4.2.5 auf 4.3.6. hochgezogen und ich hab ihm Kopf das auf 4.2.5 kein NFS v4 angeboten wurde, welcher aktuell aber eh deaktiviert ist.
    • Verbindung: Die Physikalische Verbindund der Clients zum Server funktioniert auch wenn die Freigabe nicht verfügbar ist (ping), die beiden 10er IPs sind Arbeitsplätze welche via 10Gb LWL direkt mit dem Server verbunden sind.

    Serverseitige Configs & Ausgaben

    cat /etc/config/nfssetting


    cat /etc/exports

    Code
    "/share/CACHEDEV2_DATA/Cutedrale" 10.0.1.11(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f) 10.0.2.21(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f) 192.168.178.90(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f) 192.168.178.91(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f) 192.168.178.92(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f) 192.168.178.93(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f)

"/share/CACHEDEV1_DATA/Public" *(rw,async,subtree_check,insecure,no_root_squash,fsid=37b143ba0ca575d37a356ab03a7a28db)


    ls -ld /share/CACHEDEV2_DATA/Cutedrale

    Code
    drwxrwxrwx 39 admin administrators 4096 2019-05-21 14:40 /share/CACHEDEV2_DATA/Cutedrale


    getfacl /share/CACHEDEV2_DATA/Cutedrale


    Ich versuche aktuell herauszufinden welche Version des NFS Daemons unter 4.2.5 lief und welcher es nun unter 4.3.6. ist wenn ich v2/v3 aktiviere.


    Clientseitige Configs

    cat /etc/auto_nfs

    Code
    Cutedrale -fstype=nfs,rw,bg,hard,intr,tcp 192.168.178.20:/Cutedrale


    cat /etc/autofs.conf

    Code
    AUTOMOUNT_TIMEOUT=3600
AUTOMOUNTD_MNTOPTS=nosuid,nodevi,resvport
AUTOMOUNTD_NOSUID=TRUE


    cat /etc/auto_master

    Code
    +auto_master        # Use directory service
/net            -hosts        -nobrowse,hidefromfinder,nosuid
/home            auto_home    -nobrowse,hidefromfinder
/Network/Servers    -fstab
/-            -static
/Qnap            /etc/auto_nfs


    Ansonsten freue ich mich natürlich wenn jemand noch Hinweise hat, womit sich der Fehler eingrenzen oder finden lässt.


    Stay tuned!


    Grüße

    Einmal editiert, zuletzt von d0b () aus folgendem Grund: Client Config added + fipptehler fix

    Ich habe in der Zwischenzeit bereits einen neuen Server gekauft & produktiv eingerichtet, da ich selbst nicht mehr weiter wusste, der QNAP Support noch hier noch sonstwo jemand hilfreiche Tipps zur Ergreifung des Fehler liefern konnte. Schade, denn ich würde gerne mir und anderen dieses Leid in Zukunft ersparen, nun denn.


    Ich habe beim aktuellen Setup alle Rechte einen Benutzer und einer Gruppe gegeben die dediziert für diese Freigabe arbeiten und die Zugriffsoption auf "ALL_Squash" gesetzt und allen den erstellten dedizierten User sowie Gruppe zugewiesen. Bisher läuft es wieder ohne Störungen seit nun 4 Wochen.


    Hier noch ein paar Tips zum Troubleshooting mit NFS:


    In der Nachfolgenden Fehlersuche gehen wir mal davon aus der Server die IP-Adresse 192.168.23.23 hat und der Client sich im gleichen Netz befindet mit einer abweichende IP-Adresse (z.B. 192.168.23.42).

    • Physikalische Verbindung prüfen (Client: Ping 192.168.23.23)
    • NFS Daemon neu starten (Server: /etc/init.d/nfs restart)
    • Prüfen ob RPC Messages durch das Netzwerk gelassen werden (Firewall Log prüfen)
    • Prüfen ob der entsprechende RPC Dienst läuft
      • Server: "rpc.nfsd -d"
      • Client: "rpcinfo -p 192.168.23.23"
    • Funktioniert die Freigabe (Client: showmount -e 192.168.23.23)
    • Freigabe neu verbinden (Client: umount, mount)
    • Wenn es hier noch Probleme gibt Netzwerkpakete mitschneiden (z.B. mit Wireshark), ggfs. helfen nachfolgende Befehle auch den Fehler einzugrenzen (Shell):
      • ls -ld /pfad/zur/freigabe
      • getfacl /pfad/zur/freigabe
      • dmesg | grep NFS*
      Links: * NFS fsid: https://linux.die.net/man/5/exports


      Grüße