abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 18:11 | Nová verze

    Byla vydána nová verze 5.1 svobodného 3D softwaru Blender. Přehled novinek i s náhledy a videi v poznámkách k vydání. Videopředstavení na YouTube.

    Ladislav Hagara | Komentářů: 0
    dnes 04:55 | Nová verze

    Bylo oznámeno vydání nové verze 8.1 "Hoare" kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie). Doprovodný příspěvek na blogu Khronosu rozebírá kódování a dekódování videa pomocí Vulkan Compute Shaders v FFmpeg.

    Ladislav Hagara | Komentářů: 3
    dnes 04:33 | Zajímavý projekt

    Byl představen open-source a open-hardware prototyp nízkonákladového raketometu kategorie MANPADS, který byl sestaven z běžně dostupné elektroniky a komponent vytištěných na 3D tiskárně. Raketa využívá skládací stabilizační křidélka a canardovou stabilizaci aktivně řízenou palubním letovým počítačem ESP32, vybaveným inerciální měřicí jednotkou MPU6050 (gyroskop a akcelerometr). Přenosné odpalovací zařízení obsahuje GPS,

    … více »
    NUKE GAZA! 🎆 | Komentářů: 27
    včera 14:22 | IT novinky

    Vědci z univerzity La Sapienza v Římě vyvinuli systém, který dokáže identifikovat jednotlivce pouze na základě toho, jak narušují signály Wi-Fi. Autoři tuto novou technologii nazvali WhoFi. Na rozdíl od tradičních biometrických systémů, jako jsou skenery otisků prstů a rozpoznávání obličeje, nevyžaduje tato metoda přímý fyzický kontakt ani vizuální vstupy. WhoFi může také sledovat jednotlivce na větší ploše než kamera s pevnou polohou; stačí, je-li k dispozici Wi-Fi síť.

    Ladislav Hagara | Komentářů: 11
    včera 04:22 | Nová verze

    SuperTux (Wikipedie), tj. klasická 2D plošinovka inspirovaná sérií Super Mario, byl vydán v nové verzi 0.7.0. Videoukázka na YouTube. Hrát lze i ve webovém prohlížeči.

    Ladislav Hagara | Komentářů: 7
    včera 03:11 | Zajímavý projekt

    Ageless Linux je linuxová distribuce vytvořená jako politický protest proti kalifornskému zákonu o věkovém ověřování uživatelů na úrovni OS (AB 1043). Kromě běžného instalačního obrazu je k dispozici i konverzní skript, který kompatibilní systém označí za Ageless Linux a levné jednodeskové počítače v ceně 12$ s předinstalovaným Ageless Linuxem, které se chystají autoři projektu dávat dětem. Ageless Linux je registrován jako operační

    … více »
    NUKE GAZA! 🎆 | Komentářů: 9
    15.3. 15:33 | Humor

    PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují

    … více »
    NUKE GAZA! 🎆 | Komentářů: 3
    15.3. 14:33 | Nová verze Ladislav Hagara | Komentářů: 3
    15.3. 12:33 | Zajímavý projekt

    FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.

    NUKE GAZA! 🎆 | Komentářů: 5
    14.3. 22:55 | IT novinky

    Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.

    Ladislav Hagara | Komentářů: 2
    Které desktopové prostředí na Linuxu používáte?
     (16%)
     (7%)
     (0%)
     (11%)
     (29%)
     (2%)
     (5%)
     (1%)
     (13%)
     (24%)
    Celkem 1098 hlasů
     Komentářů: 26, poslední 12.3. 08:56
    Rozcestník

    Dotaz: problém s NFS serverem po výpadku napájení - nelze přimountovat

    Pavel Čejka avatar 15.10.2019 13:35 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    problém s NFS serverem po výpadku napájení - nelze přimountovat
    Přečteno: 1120×

    Narazil jsem na zvláštnost, kterou se mi nedaří zatím lépe diagnostikovat. Po výpadku napájení na jednom z domácích serverů (nepříjemné, nutno řešit, ale nikoli fatálně kritické) přestalo být možné namountovat exportovaný NFS svazek - čímkoli.

    Na serveru je nyní Gentoo, jádro 4.19.50, nebo 4.9.63 (zkoušel jsem obě verze) a bude 4.9.79, net-fs/nfs-utils-2.4.1-r1, jádro má zapnutou podporu verzí NFS 3 i 4.

    Připojovat jsem se zkoušel jiným Gentoo s podobnými verzemi jádra i nfs-utils, Debianem 10 i serverem samotným - vše se stejným výsledkem, takže problém na klientech jsem vyloučil.

    Dejme tomu, že exportuji složku __public, nijak nezáleží na tom, co vlastně exportuji a odkud, nebo s jakými volbami, ono to nakonec nefunguje stejně.

    /home/__public 192.168.0.254(rw,async,all_squash,anonuid=65534,anongid=65533,no_subtree_check)

    Připomínám, že v konfiguraci iptables změna nenastala a zkouším i přes localhost, kde není omezení žádné.

    Pokus o mount dopadá takto:

    mount -t nfs -o nfsvers=3 jmenoserveru:/home/__public /mnt/hdd/
    mount.nfs: Stale file handle
    umount /mnt/hdd
    umount: /mnt/hdd: nepřipojeno.
    mount -t nfs -o nfsvers=4 jmenoserveru:/home/__public /mnt/hdd/

    Mount bez explicitně zadané verze NFS se pokusí použít verzi 4.

    Pokud by sožka nebyla exportována, tak pokus o mount selže se správnou chybou. Taktéž i pokud nejsou dostatečná práva atd...

    Zkusil jsem exportovat složku z BTRFS a při pokusu o připojení to skončí vždy chybou mount.nfs: Stale file handle bez ohledu na verzi NFS.

    ls /mnt/hdd
    ls: adresář '/mnt/hdd' nelze otevřít: Zastaralý ukazatel na soubor
    
    cd /mnt/hdd 
    bash: cd: /mnt/hdd: Zastaralý ukazatel na soubor
    
    mount
    ...
    jmenoserveru:/home/__public on /mnt/hdd type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.254,local_lock=none,addr=192.168.0.254)

    V logu se nezdá být cokoli užitečného:

    Oct 15 12:29:34 jmenoserveru start-stop-daemon[17414]: Will stop /usr/sbin/rpc.mountd
    Oct 15 12:29:34 jmenoserveru rpc.mountd[8523]: Caught signal 15, un-registering and exiting.
    Oct 15 12:29:35 jmenoserveru start-stop-daemon[17418]: Will stop nfsd
    Oct 15 12:29:35 jmenoserveru kernel: nfsd: last server has exited, flushing export cache
    Oct 15 12:29:35 jmenoserveru start-stop-daemon[17449]: Will stop /sbin/rpc.statd
    Oct 15 12:29:35 jmenoserveru start-stop-daemon[17477]: Will stop /usr/sbin/rpc.idmapd
    Oct 15 12:29:35 jmenoserveru start-stop-daemon[17504]: Will stop /sbin/rpcbind
    Oct 15 12:29:36 jmenoserveru rpc.idmapd[17586]: Setting log level to 0
    Oct 15 12:29:36 jmenoserveru rpc.statd[17598]: Version 2.3.4 starting
    Oct 15 12:29:36 jmenoserveru rpcbind[17597]: connect from 127.0.0.1 to getport/addr(status)
    Oct 15 12:29:36 jmenoserveru rpc.statd[17598]: Flags: TI-RPC 
    Oct 15 12:29:36 jmenoserveru rpc.statd[17598]: Running as root.  chown /var/lib/nfs to choose different user
    Oct 15 12:29:36 jmenoserveru rpc.mountd[17636]: Version 2.3.4 starting
    Oct 15 12:29:36 jmenoserveru kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
    Oct 15 12:29:53 jmenoserveru rpcbind[17663]: connect from 127.0.0.1 to getport/addr(status)
    Oct 15 12:29:53 jmenoserveru rpcbind[17664]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:29:53 jmenoserveru rpcbind[17665]: connect from 192.168.0.254 to getport/addr(mountd)
    Oct 15 12:29:53 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:800 for /home/__public (/home/__public)
    Oct 15 12:29:53 jmenoserveru rpcbind[17666]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:29:54 jmenoserveru rpcbind[17667]: connect from 127.0.0.1 to getport/addr(status)
    Oct 15 12:29:54 jmenoserveru rpcbind[17668]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:29:54 jmenoserveru rpcbind[17669]: connect from 192.168.0.254 to getport/addr(mountd)
    Oct 15 12:29:54 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:752 for /home/__public (/home/__public)
    Oct 15 12:29:54 jmenoserveru rpcbind[17670]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:29:56 jmenoserveru rpcbind[17671]: connect from 127.0.0.1 to getport/addr(status)
    Oct 15 12:29:56 jmenoserveru rpcbind[17672]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:29:56 jmenoserveru rpcbind[17673]: connect from 192.168.0.254 to getport/addr(mountd)
    Oct 15 12:29:56 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:885 for /home/__public (/home/__public)
    Oct 15 12:29:56 jmenoserveru rpcbind[17674]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:49:17 jmenoserveru rpcbind[17830]: connect from 127.0.0.1 to getport/addr(status)
    Oct 15 12:49:17 jmenoserveru rpcbind[17831]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:49:17 jmenoserveru rpcbind[17832]: connect from 192.168.0.254 to getport/addr(mountd)
    Oct 15 12:49:17 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:828 for /home/__public (/home/__public)
    Oct 15 12:49:17 jmenoserveru rpcbind[17833]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:49:18 jmenoserveru rpcbind[17834]: connect from 127.0.0.1 to getport/addr(status)
    Oct 15 12:49:18 jmenoserveru rpcbind[17835]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:49:18 jmenoserveru rpcbind[17836]: connect from 192.168.0.254 to getport/addr(mountd)
    Oct 15 12:49:18 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:960 for /home/__public (/home/__public)
    Oct 15 12:49:18 jmenoserveru rpcbind[17837]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:49:20 jmenoserveru rpcbind[17838]: connect from 127.0.0.1 to getport/addr(status)
    Oct 15 12:49:20 jmenoserveru rpcbind[17839]: connect from 192.168.0.254 to getport/addr(nfs)
    Oct 15 12:49:20 jmenoserveru rpc.mountd[17636]: authenticated mount request from 192.168.0.254:750 for /home/__public (/home/__public)
    Oct 15 12:49:20 jmenoserveru rpcbind[17840]: connect from 192.168.0.254 to getport/addr(mountd)
    Oct 15 12:49:20 jmenoserveru rpcbind[17841]: connect from 192.168.0.254 to getport/addr(nfs)

    Kdesi jsem se dočetl, že chyba Stale file handle by snad mohla souviset s nějakým zámkem po špatně odmountovaném svazku, ale nenašel jsem žádný detail, jak zjistit jaký konkrétně, jediné doporučení tam byl reboot. To jsem udělal opakovaně při změně jádra za jinou verzi. Nemělo to vliv.

    Úplně původně jsem ani verzi NFS 4.x neměl povolenou, pro interní síť a dvě klientská PC mi v pohodě stačila verze 3.

    HDD, ze kterého exportuji NFS má ReiserFS na dvou oddílech. Zkusil jsem exportovat jinou složku z jiného oddílu - žádný rozdíl.

    Zkusil jsem promazat /var/lib/nfs/rmtab, žádný vliv. Pouze se přimountováním v rmtab vytvoří nový záznam. Další soubory v /var/lib/nfs jsou většinou prázné (0 bytů), kromě etab, obsahuje seznam exportovaných svazků a state, obsahuje nějaké 4 byty. Význam neznám.

    Zkusil jsem HDD otestovat pomocí readonly badblocks -sv /dev/sda, vše ok. SMART ok, žádné chyby ve výpisu.

    Ze zoufalství jsem zkusil přes noc i emerge -ave world, pro případ, že by výpadkem napájení došlo k poškození nějaké s NFS související knihovny. Nepomohlo. Všechny soubory jsou čerstvě zkompilované, včetně jádra, kontrolní součty balíčků ověřené, vše ok. Jen NFS nefunguje.

    V conf.d jsou konfiguráky nfs a rpcbind, nfs je defaultní neprováděl jsem v něm změny.

    # /etc/conf.d/nfs
    
    # If you wish to set the port numbers for lockd,
    # please see /etc/sysctl.conf
    
    # Optional services to include in default `/etc/init.d/nfs start`
    # For NFSv4 users, you'll want to add "rpc.idmapd" here.
    NFS_NEEDED_SERVICES="rpc.idmapd"
    
    # Options to pass to rpc.nfsd
    OPTS_RPC_NFSD="8"
    
    # Options to pass to rpc.mountd
    # ex. OPTS_RPC_MOUNTD="-p 32767"
    OPTS_RPC_MOUNTD=""
    
    # Options to pass to rpc.statd
    # ex. OPTS_RPC_STATD="-p 32765 -o 32766"
    OPTS_RPC_STATD=""
    
    # Options to pass to rpc.idmapd
    OPTS_RPC_IDMAPD=""
    
    # Options to pass to rpc.gssd
    OPTS_RPC_GSSD=""
    
    # Options to pass to rpc.svcgssd
    OPTS_RPC_SVCGSSD=""
    
    # Options to pass to rpc.rquotad (requires sys-fs/quota)
    OPTS_RPC_RQUOTAD=""
    
    # Timeout (in seconds) for exportfs
    EXPORTFS_TIMEOUT=30
    
    # Options to set in the nfsd filesystem (/proc/fs/nfsd/).
    # Format is <option&rt;=<value&rt;.  Multiple options are allowed.
    #OPTS_NFSD="nfsv4leasetime=30 max_block_size=4096"

    Do rpcbind jsem zkusil přidat volbu -d jako debug.

    # /etc/conf.d/rpcbind
    .
    # Options for `rpcbind`.
    #RPCBIND_OPTS="-l"
    
    RPCBIND_OPTS="-l -d"

    Výsledkem -d je alespoň to málo ve /var/log/messages, co jsem přiložil, jinak by nebylo ani to.

    V dmesg nic.

    Nějaký další nápad?


    Řešení dotazu:


    Odpovědi

    15.10.2019 13:44 NN
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat
    Souborovy system jsi nekontroloval? Neco ve stylu raiserfsck --check /dev/xyz?
    Pavel Čejka avatar 15.10.2019 14:03 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat
    Kontroloval, kontrolu zopakoval, je ok. Ostatně žurnál se přehrává při prvním přimountování.

    Hlavně jsem zkoušel exportovat z různých filesystémů, i BTRFS, nejenom z ReiserFS.
    Replaying journal: Done.
    Reiserfs journal '/dev/sda3' in blocks [18..8211]: 0 transactions replayed
    Checking internal tree.. finished                                
    Comparing bitmaps..finished
    Checking Semantic tree:
    finished                                                                       
    No corruptions found
    There are on the filesystem:
            Leaves 101963
            Internal nodes 648
            Directories 4032
            Other files 204770
            Data block pointers 54142197 (0 of them are zero)
            Safe links 0
    Max avatar 15.10.2019 14:04 Max | skóre: 72 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat
    Zkus reexport a zkontroluj, jak to vypadá :
    exportfs -ua
    exportfs -a
    
    # nebo
    exportfs -f
    
    Zdar Max
    Měl jsem sen ... :(
    Pavel Čejka avatar 15.10.2019 14:16 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat
    I to už jsem zkoušel (všechny navrhované kombinace parametrů), zkusil jsem opět, stále se stejným výsledkem.
    cat /proc/fs/nfsd/versions 
    -2 +3 +4 +4.1 +4.2

    Ad use flagy:

    [ebuild   R    ] net-fs/nfs-utils-2.4.1-r1::gentoo  USE="caps ipv6 libmount nfsidmap nfsv4 nfsv41 tcpd uuid -junction -kerberos -ldap -nfsdcld (-selinux)" 0 KiB

    A konfigurace jádra:

    CONFIG_KERNFS=y
    CONFIG_NFS_FS=m
    CONFIG_NFS_V2=m
    CONFIG_NFS_V3=m
    # CONFIG_NFS_V3_ACL is not set
    CONFIG_NFS_V4=m
    # CONFIG_NFS_SWAP is not set
    CONFIG_NFS_V4_1=y
    CONFIG_NFS_V4_2=y
    CONFIG_PNFS_FILE_LAYOUT=m
    CONFIG_PNFS_BLOCK=m
    CONFIG_PNFS_FLEXFILE_LAYOUT=m
    CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
    CONFIG_NFS_V4_1_MIGRATION=y
    CONFIG_NFS_FSCACHE=y
    CONFIG_NFS_USE_LEGACY_DNS=y
    CONFIG_NFS_DEBUG=y
    CONFIG_NFSD=y
    CONFIG_NFSD_V3=y
    # CONFIG_NFSD_V3_ACL is not set
    CONFIG_NFSD_V4=y
    CONFIG_NFSD_PNFS=y
    CONFIG_NFSD_BLOCKLAYOUT=y
    CONFIG_NFSD_SCSILAYOUT=y
    CONFIG_NFSD_FLEXFILELAYOUT=y
    CONFIG_NFS_COMMON=y
    Pavel Čejka avatar 15.10.2019 23:24 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat

    Další pokus, aktualizoval jsem jádro na verzi 5.3.0 a problém je stále stejný.

    showmount -a vypíše zapamatované klienty s mountpointy, ale i když je prázdný a nenastane hláška mount.nfs: Stale file handle, tak to nefunguje.

    Nejukecanější mount je k ničemu

    mount.nfs: timeout set for Tue Oct 15 22:52:14 2019
    mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.254,clientaddr=192.168.0.1'

    NFS (4.2) se přimountuje bez stížností, ale nelze s ní pracovat, jakýkoli pokus končí nelze přistoupit k '/mnt/nfs': Zastaralý ukazatel na soubor.

    A opět, nezáleží na tom, jestli je klient Gentoo, nebo Debian... čímž chci říct, že to není vada jednoho klienta. Ani to není omezení firewallu, do vnitřní sítě omezení iptables není.

    Ukecaný pokus o přimountování NFS verzí 3 skončí vždy takto.

    mount.nfs: timeout set for Tue Oct 15 23:01:48 2019
    mount.nfs: trying text-based options 'nfsvers=3,addr=192.168.0.254'
    mount.nfs: prog 100003, trying vers=3, prot=6
    mount.nfs: trying 192.168.0.254 prog 100003 vers 3 prot TCP port 2049
    mount.nfs: prog 100005, trying vers=3, prot=17
    mount.nfs: trying 192.168.0.254 prog 100005 vers 3 prot UDP port 42259
    mount.nfs: mount(2): Stale file handle
    mount.nfs: trying text-based options 'nfsvers=3,addr=192.168.0.254'
    mount.nfs: prog 100003, trying vers=3, prot=6
    mount.nfs: trying 192.168.0.254 prog 100003 vers 3 prot TCP port 2049
    mount.nfs: prog 100005, trying vers=3, prot=17
    mount.nfs: trying 192.168.0.254 prog 100005 vers 3 prot UDP port 42259
    mount.nfs: mount(2): Stale file handle
    mount.nfs: trying text-based options 'nfsvers=3,addr=192.168.0.254'
    mount.nfs: prog 100003, trying vers=3, prot=6
    mount.nfs: trying 192.168.0.254 prog 100003 vers 3 prot TCP port 2049
    mount.nfs: prog 100005, trying vers=3, prot=17
    mount.nfs: trying 192.168.0.254 prog 100005 vers 3 prot UDP port 42259
    mount.nfs: mount(2): Stale file handle
    mount.nfs: Stale file handle

    Proč?

    I když koukám na komunikaci tcpdumpem a vidím, že oba stroje spolu komunikují, tak z toho nedovedu vykoukat víc, než že komunikace mezi nimi končí tímto:

    NFS reply xid 3824853766 reply ok 88 getattr ERROR: Stale NFS file handle

    Jak to donutit k nějakému ukecanějšímu výstupu ... kdekoli, ze kterého se dá něco dalšího poznat? Jediné, co jsem dokázal vypátrat, že se v minulých letech (jako např. 2008, 2012, 2014) různé bugy různým lidem s různými verzemi nfs-utils staly. Nic, co by pomohlo.

    Zkusím prozatím updatnout to Gentoo, už to je asi 14 dnů od poslední aktualizace, třeba bude jiná verze nfs-utils.

    16.10.2019 08:34 NN
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat
    Muzes na tom stroji nabootovat live nejaky uplne jiny system?
    Pavel Čejka avatar 16.10.2019 13:41 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat
    Můžu, ale nechávám si to jako úplně poslední možnost. Poskytuje další služby a nechci zbytečně prodlužovat výpadek. NFS je jen pro mě.
    16.10.2019 08:36 Izidor
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat
    Možná může být problém s pořadím spouštění služeb, viz zde: https://unix.stackexchange.com/questions/543363/stale-file-handle-after-server-reboot
    Pavel Čejka avatar 16.10.2019 13:39 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat
    Jinde jsem se dočel, že může mít vliv pořadí restartu client/server, což jsem mimochodem vyzkoušel a nepomohlo.

    Mimochodem, nemám na Gentoo systemd.

    Smysl by to dávalo, pokud by se netmount (nfsmount) skript spouštěl před sítí a pod... ale to se neděje, pokud zkusím mount ručně, nebo restatuju netmount společně s rpcbind dávno po nabootování a spuštění všeho ostatního.
    Řešení 1× (Pavel Čejka (tazatel))
    Pavel Čejka avatar 16.10.2019 13:43 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat
    V tuto chvíli to vypadá tak, že možná šlo u bug net-fs/nfs-utils-2.4.1-r1, který řeší net-fs/nfs-utils-2.4.1-r2

    Nečekaným rebootem se prostě použila po updatu připravená verze s chybou.

    Večer vyzkouším a potvrdím, je-li to opravdu tak.
    Pavel Čejka avatar 17.10.2019 00:43 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    Rozbalit Rozbalit vše Re: problém s NFS serverem po výpadku napájení - nelze přimountovat
    Vyzoušel jsem a skutečně to funguje, ale pouze NFS 3.

    Zkusím-li klientem použít NFS verze 4.2, tak NFS server padne a ukončí se, nutno restartovat. Takže je v tom ještě cosi shnilého. Ale NFS verze 3 funguje a to mi prozatím stačí. Podporu NFS 4.x ze serveru prozatím odstraním zcela.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.