LaCie 2Big Network: supporto nfs

No, I will not fix your pc.
[Detto anonimo e largamente condiviso]

Aggiornamento / Update (05/02/2012):

Per il servizio nfsd in kernelspace, guardate i commenti di questo stesso articolo.
Suggerisco di usare il servizio nfsd in kernelspace, dato che supporta il lock dei file.

For nfsd kernel space, look at the comments of this article.
I recommend to use nfs kernel space since it supports file locking.

All thanks go to Bert.


Avevo tentato precedentemente di installare il supporto nfs sul mio vecchio (v1) nas 2Big Network della LaCie ma avevo desistito per la mancanza del modulo kernel nfsd, che permette di abilitare nfs server in kernelspace.

Di recente, dopo una richiesta di aiuto da parte di un navigatore, ho riaffrontato il problema trovando una soluzione: nsf in spazio utente. Ok storco il naso anche io per l’enormità di quello che ho appena detto..
Infatti ci sono grossi handicap per nfs userspace: lo sviluppo del codice è stato completamente abbandonato (l’ultima versione è la 0.9.22 e risale al 05/01/2009), ma il problema più grave che non vi è alcun supporto per il lock dei file.

Per installare il supporto per nfs v3 sul nas c’è bisogno dei demoni unfsd e portmap, il primo è nfs stesso il secondo è un servizio ONC RPC, in esecuzione su una macchina collegata in rete, che fornisce altri servizi ONC RPC (Remote Procedure Call). (Chi è abituato a programmare sa di che sto parlando)
Per farla breve il pacchetto unfs3 dipende dal pacchetto portmap. Ai fini pratici significa che è richiesto  l’installazione anche del servizio portmap per avere nfs funzionante.
Significa anche che ho dovuto scrivere due script per initng per avviare/arrestare correttamente i due demoni.

File portmap.i:

# NAME: portmap
# DESCRIPTION: DARPA port to RPC program number mapper
# WWW: 

# exec daemon = /sbin/portmap -d ${PORTMAP_OPTS};
daemon portmap {
	need = bootmisc virtual/net;
	provide = virtual/portmap;
	pid_file = /var/run/portmap.pid;
	forks;
	env PORTMAP_OPTS=;
	env_file = /etc/portmap.conf;
	exec daemon = /sbin/portmap;
}

File unfs3.i:

# NAME: unfs3
# DESCRIPTION: starts user-space NFSv3 server.
#	       UNFS3 is a user-space implementation of the NFSv3 server specification.
#	       It provides a daemon for the MOUNT and NFS protocols,
#	       which are used by NFS clients for accessing files on the server.
#	       Unlike nfs-user-server, unfs3 is capable of handling files larger than 2GB,
#              but there is currently no support for file locking.
# WWW:

daemon unfs3 {
	need = initial virtual/portmap virtual/net;
	env PID_FILE = /var/run/unfsd.pid;
	env_file = /etc/unfs3.conf;
	pid_file = ${PID_FILE};
	require_network;
	forks;
	exec daemon = /usr/sbin/unfsd -i ${PID_FILE} $DAEMON_OPTS;
	daemon_stops_badly;
}

Installazione di nfs3 server

Come premessa generale si presuppone che:

  • abbiate già effettuato l’hack del vostro nas (vedi articolo),
  • installato ssh e soprattutto con esso le librerie tcp-wrappers,
  • avete un account di root sul vostro nas (tutte operazioni documentate nell’articolo già citato)
  • e sopratutto, una buona padronanza della bash e dei sistemi linux.

Per installare nfs server dovete scaricare questi due archivi:

I pacchetti sono stati scaricati della distro debian lenny e sono compilati per armtel, da entrambi gli archivi ho eliminato i man page e i doc al fine di recuperare tutto lo spazio possibile.
Ho spostato il file di configurazione di portmap nella cartella /etc e l’ho rinominato in portmap.conf.
Il demone unfsd ha in file di configurazione proprio (da non confondere con il file /etc/exports) che ho rinominato in unfs3.conf e inserito anch’esso nella cartella /etc.
Queste modifiche erano dovute dato che l’architettura del nas differisce dall’architettura di un sistema operativo debian. Gli script per initng riflettono queste modifiche per cui se cambiate posto a quei file dovrete modificare di conseguenza gli script di avvio dei demoni.

Copiate l’archivio nella vostra cartella condivisa del nas.

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvzf portmap_6.0-9_armel.tar.gz -C /
# tar -xvzf unfs3_0.9.21_armel.tar.gz -C /
# rm portmap_6.0-9_armel.tar.gz
# rm unfs3_0.9.21_armel.tar.gz
# cd /etc/initng/runlevel/
# echo portmap >> default.runlevel
# echo unfs3 >> default.runlevel

Adesso dovete configurare il file exports che indica al demone nfs quali cartelle deve condividere nella vostra rete locale:

# vi /etc/exports

Vi ricordo che i comandi per modificare un file con l’editor vi sono “i” per inserire nuovo testo e “ESC”+“:wq” per salvare e uscire, “ESC”+“:q!” per forzare l’uscita dal file senza salvare le modifiche apportate.

La configurazione del file in questione la lascio alla vostra esperienza personale, se state installando nfs sul nas si presuppone che sappiate quello che state facendo. Vi informo tuttavia che questa versione di nfs (unfs3) non supporta nfs v4 ne nfs v2, inoltre non supporta nemmeno alcuni tag di configurazione come sync.

Non ho voluto implementare il supporto per nfs v2 perché assolutamente obsoleto, infatti un client nfs presuppone che, se non diversamente specificato, il protocollo, che deve usare per condividere in locale una cartella esportata da una macchina remota, sia nfs v3. Per finire nfs v2 non supporta file di dimensione superiore a i 2Gb.

Una volta configurato il file exports potete riavviare la macchina o se preferite avviare manualmente i demoni con i comandi:

# ngc -u portmap
# ngc -u unfs3

Per maggiori informazioni su ngc, digitate:

# ngc -h

E dire che questo nas non lo uso neanche più…

Aggiornamento.

Ho modificato nuovamente lo script unfs3.i inserendo la riga require_network a causa dell’avvio immediato del demone unfsd da parte di initng (prima ancora che l’interfaccia di rete lan fosse attiva). Il demone unfsd non pubblicava la socket sull’indirizzo di rete locale impedendo l’accesso da remoto.

La clausola require_network impone ad initng di attendere che l’interfaccia di rete della lan sia attiva prima di avviare il server unfsd: problema risolto.

Rsync

Script di avvio per rsync. (Il programma è già incluso nel nas)
File rsyncd.i:

#!/sbin/itype

# Short-Description: fast remote file copy program daemon
# Description: rsync is a program that allows files to be copied to and
# from remote machines in much the same way as rcp.
# This provides rsyncd daemon functionality.

daemon rsyncd {
       need = bootmisc virtual/net;
       require_network;
       env RSYNC_CONFIG_FILE=/etc/rsyncd.conf;
       env_file = ${RSYNC_CONFIG_FILE};
       exec daemon = /usr/bin/rsync --daemon --no-detach --config ${RSYNC_CONFIG_FILE};
       daemon_stops_badly;
}

Per maggiori informazioni su rsync vedere nei commenti di questo stesso articolo.

10 pensieri su “LaCie 2Big Network: supporto nfs

  1. Great HowTo!!! even when I had to use Google translate to understand everything 😉

    Keep going on this good work.

  2. Ciao,
    innanzi tutto complimenti per le guide, sul Lacie 2big Network. Mi sono state utilissime per configurare questo NAS.
    Adesso che ho costruito il mio NAS vorrei usare questo Lacie per fare i backup del NAS principale tramite rsync.
    Il Lacie ha gia’ rsync installato, ma vorrei far partire il daemon (rsync –daemon) al boot.
    Questo richiede un file .i dell’initng e qui scatta la mia richiesta di aiuto: potresti aiutarmi a scriverlo? Non ti sto chiedendo di scrivermelo, ma potresti indicarmi dove documentarmi?

    Grazie.

  3. Documentazione? hahahahahahahah….. aaaah.. Si, come no.
    Questo è il meglio che sono riuscito a trovare… http://pkgs.fedoraproject.org/repo/pkgs/initng-ifiles/
    Sono dei package per gli script initng per fedora e gentoo. File che vanno modificati pesantemente comunque.
    Non so nemmeno so lo sviluppano più il progetto initng.

    Va bhe.
    Sul nas è installato rsync v3.0.3. Quindi per riferimento ho scaricato il package rsync della debian lenny. (http://packages.debian.org/lenny/rsync)
    Altrimenti un esempio pratico per il file di configurazione di rsync (/etc/rsync.conf) non avrei saputo proprio dove andare a trovarlo.
    Dentro l’archivio di rsync (package debian lenny) c’è un esempio del file rsync.conf dentro la cartella /usr/doc/rsync/examples
    Attenzione le righe:
    # for pid file, do not use /var/run/rsync.pid if
    # you are going to run rsync out of the init.d script.
    pid file=/var/run/rsyncd.pid

    del file rsync.conf sono da eliminare.
    Devi crearlo il file sul nas perché manca ok?

    Mentre il file di configurazione per rsync testato sul mio nas è questo:


    #!/sbin/itype

    # Short-Description: fast remote file copy program daemon
    # Description: rsync is a program that allows files to be copied to and
    # from remote machines in much the same way as rcp.
    # This provides rsyncd daemon functionality.

    daemon rsyncd {
    need = bootmisc virtual/net;
    require_network;
    env RSYNC_CONFIG_FILE=/etc/rsyncd.conf;
    env_file = ${RSYNC_CONFIG_FILE};
    exec daemon = /usr/bin/rsync --daemon --no-detach --config ${RSYNC_CONFIG_FILE};
    daemon_stops_badly;
    }

    Attento a non caricare troppo il nas di servizi attivi: la sua ram è fin troppo poca.

    Spero di esserti stato di aiuto.
    ps. un punto di demerito: mi hai fatto usare nuovamente l’editor “vi” :-p
    “ESC”:wq

    ps. 2)
    Ho appena ricevuto una mail con oggetto “Mail delivery failed: returning message to sender”.
    Sembra che tu ti sia inscritto ai commenti di questo post con una mail inesistente. (The email account that you tried to reach does not exist. ecc..)
    Controlla.

  4. Uau,
    grazie mille! Non mi aspettavo tanto, sei un mito!

    Mi dispiace per vi… ma non si puo’ pretendere molto da questo NAS 🙂 Tra l’altro per il problema della ram pensavo infatti di disattivare il servizio samba e ftp che tanto non mi servono piu’.

    Solo due commenti.
    Io ho gia’ creato il mio file rsyncd.conf e sulla documentazione http://www.samba.org/ftp/rsync/rsyncd.conf.html non ho letto niente riguardo all’uso del parametro “pid file” con init.d. Boh, lo togliero’ e usera’ il suo default, non e’ una tragedia.

    La seconda domanda e’: come mai hai usato l’opzione –no-detach quando lanci il deamon?

    Ciao e grazie ancora.

    P.S. Per la mail… mea culpa, ho usato google.com invece di googlemail.com come dominio (solo e soltanto in Germania il dominio gmail.com e’ occupato e hanno dovuto usare googlemail.com… bruttissimo).

  5. Per quanto riguarda il pid file si presuppone che rsyncd lo crei col nome /var/run/rsyncd.pid,
    ma il file manca nella cartella anche quando il programma è attivo come demone.
    Quindi il mio consiglio è semplicemente di bypassare ogni configurazione del pid di rsync, dato che genera solo problemi.

    In una prima stesura dello script per rsyncd avevo dichiarato la path e la variabile per il file pid:
    pid_file = /var/run/rsyncd.pid;
    ed è stata una pessima idea, ngc si piantava sull’attesa del file rsyncd.pid, (che il programma non creava) per cui falliva il lancio del demone rsyncd.
    Sempre per lo stesso motivo ngc (initng) non è in grado di sapere se il demone è realmente attivo o no, quindi in fase di arresto del demone andava in errore.
    Ecco spiegato il motivo della riga: daemon_stops_badly;
    Se riesci a fare capire a rsyncd che deve creare il suo file pid, allora si può modificare il suo script di avvio di conseguenza.

    Per quanto riguarda l’opzione --no-detach, bhe mi sono rifatto ad un file initng per rsync che ho trovato negli archivi di fedora (il link è nel mio commento precedente).
    Il file non funziona sul nas (ovviamente), sia perché è stato scritto per una versione differente di initng, sia perché la configurazione del nas stessa è differente da fedora/gentoo.
    (tipo non esiste la cartella /etc/initng/daemon, non esiste la cartella /etc/initng/system, ecc..)

    Io rsync l’ho sempre e solo usato lato client, non ho avuto ma l’esigenza di lanciarlo come demone, quindi la mia conoscenza sulle impostazioni di rsync “server” sono un po limitate.

    Spero di aver soddisfatto la tua curiosità 🙂

  6. To anyone who may be interested, i have compiled the kernel NFSD modules for the lacie 2big, using the gpl kernel code released by lacie…

    I have tested the module loading with version 2.2.8 of the lacie firmware, although i have not yet tested the userspace configuration of NFS…

    The modules (in a tarfile) can be obtained from:
    http://www.firenzee.com/modules-2big.tar.gz

    To get nfsd.ko to load, you have to load exportfs.ko, sunrpc.ko, and lockd.ko first…

    sh-3.2# lsmod
    Module Size Used by Not tainted
    nfsd 97924 0
    lockd 69976 1 nfsd
    sunrpc 170452 2 nfsd,lockd
    exportfs 4512 1 nfsd
    appletalk 31724 20
    psnap 3012 1 appletalk
    llc 5908 1 psnap
    usb_storage 68235 0
    xfs 605412 1

  7. WOW! Thanks a lot for your contribute. (Ok, i apologize for my bad English :-p )

    although i have not yet tested the userspace configuration of NFS…

    Userspace configuration of nfs is MORE or less deprecated..

    wait… i got some nasty error… ok, found the problem…

    [root@nas /oldroot/snapshots/snaps/03/lib/modules/2.6.22.7]# diff modules.dep.new /lib/modules/2.6.22.7/modules.dep
    --- modules.dep.new Fri Feb 3 17:51:20 2012
    +++ /lib/modules/2.6.22.7/modules.dep Thu Mar 4 11:43:55 2010
    @@ -1,37 +1,35 @@
    -kernel/crypto/ecb.ko:
    -kernel/crypto/pcbc.ko:
    -kernel/fs/nfsd/nfsd.ko: kernel/fs/exportfs/exportfs.ko kernel/fs/lockd/lockd.ko kernel/net/sunrpc/sunrpc.ko
    -kernel/fs/nls/nls_cp850.ko:
    -kernel/fs/nls/nls_cp437.ko:
    -kernel/fs/isofs/isofs.ko:
    -kernel/fs/lockd/lockd.ko: kernel/net/sunrpc/sunrpc.ko
    -kernel/fs/fuse/fuse.ko:
    -kernel/fs/fat/fat.ko:
    -kernel/fs/udf/udf.ko:
    -kernel/fs/nfs/nfs.ko: kernel/fs/lockd/lockd.ko kernel/net/sunrpc/sunrpc.ko
    -kernel/fs/ntfs/ntfs.ko:
    -kernel/fs/vfat/vfat.ko: kernel/fs/fat/fat.ko
    -kernel/fs/xfs/xfs.ko:
    -kernel/fs/reiserfs/reiserfs.ko:
    -kernel/fs/hfsplus/hfsplus.ko:
    -kernel/fs/msdos/msdos.ko: kernel/fs/fat/fat.ko
    -kernel/fs/cifs/cifs.ko:
    -kernel/fs/exportfs/exportfs.ko:
    -kernel/net/appletalk/appletalk.ko: kernel/net/802/psnap.ko kernel/net/llc/llc.ko
    -kernel/net/802/p8022.ko: kernel/net/llc/llc.ko
    -kernel/net/802/psnap.ko: kernel/net/llc/llc.ko
    -kernel/net/llc/llc.ko:
    -kernel/net/sunrpc/sunrpc.ko:
    -kernel/drivers/scsi/iscsi_tcp.ko: kernel/drivers/scsi/libiscsi.ko kernel/drivers/scsi/scsi_transport_iscsi.ko
    -kernel/drivers/scsi/thor/mv61xx.ko:
    -kernel/drivers/scsi/libiscsi.ko: kernel/drivers/scsi/scsi_transport_iscsi.ko
    -kernel/drivers/scsi/scsi_transport_iscsi.ko:
    -kernel/drivers/scsi/scsi_wait_scan.ko:
    -kernel/drivers/char/hw_random/rng-core.ko:
    -kernel/drivers/usb/gadget/g_serial.ko: kernel/drivers/usb/gadget/marvell_udc.ko
    -kernel/drivers/usb/gadget/g_ether.ko: kernel/drivers/usb/gadget/marvell_udc.ko
    -kernel/drivers/usb/gadget/g_file_storage.ko: kernel/drivers/usb/gadget/marvell_udc.ko
    -kernel/drivers/usb/gadget/marvell_udc.ko:
    -kernel/drivers/usb/class/usblp.ko:
    -kernel/drivers/usb/storage/usb-storage.ko:
    -kernel/drivers/md/faulty.ko:
    +/lib/modules/2.6.22.7/kernel/fs/lockd/lockd.ko: /lib/modules/2.6.22.7/kernel/net/sunrpc/sunrpc.ko
    +/lib/modules/2.6.22.7/kernel/fs/vfat/vfat.ko: /lib/modules/2.6.22.7/kernel/fs/fat/fat.ko
    +/lib/modules/2.6.22.7/kernel/fs/cifs/cifs.ko:
    +/lib/modules/2.6.22.7/kernel/fs/nfs/nfs.ko: /lib/modules/2.6.22.7/kernel/fs/lockd/lockd.ko /lib/modules/2.6.22.7/kernel/net/sunrpc/sunrpc.ko
    +/lib/modules/2.6.22.7/kernel/fs/fat/fat.ko:
    +/lib/modules/2.6.22.7/kernel/fs/reiserfs/reiserfs.ko:
    +/lib/modules/2.6.22.7/kernel/fs/ntfs/ntfs.ko:
    +/lib/modules/2.6.22.7/kernel/fs/nls/nls_cp437.ko:
    +/lib/modules/2.6.22.7/kernel/fs/nls/nls_cp850.ko:
    +/lib/modules/2.6.22.7/kernel/fs/isofs/isofs.ko:
    +/lib/modules/2.6.22.7/kernel/fs/fuse/fuse.ko:
    +/lib/modules/2.6.22.7/kernel/fs/msdos/msdos.ko: /lib/modules/2.6.22.7/kernel/fs/fat/fat.ko
    +/lib/modules/2.6.22.7/kernel/fs/xfs/xfs.ko:
    +/lib/modules/2.6.22.7/kernel/fs/hfsplus/hfsplus.ko:
    +/lib/modules/2.6.22.7/kernel/fs/udf/udf.ko:
    +/lib/modules/2.6.22.7/kernel/crypto/ecb.ko:
    +/lib/modules/2.6.22.7/kernel/crypto/pcbc.ko:
    +/lib/modules/2.6.22.7/kernel/drivers/scsi/scsi_wait_scan.ko:
    +/lib/modules/2.6.22.7/kernel/drivers/scsi/scsi_transport_iscsi.ko:
    +/lib/modules/2.6.22.7/kernel/drivers/scsi/libiscsi.ko: /lib/modules/2.6.22.7/kernel/drivers/scsi/scsi_transport_iscsi.ko
    +/lib/modules/2.6.22.7/kernel/drivers/scsi/thor/mv61xx.ko:
    +/lib/modules/2.6.22.7/kernel/drivers/scsi/iscsi_tcp.ko: /lib/modules/2.6.22.7/kernel/drivers/scsi/libiscsi.ko /lib/modules/2.6.22.7/kernel/drivers/scsi/scsi_transport_iscsi.ko
    +/lib/modules/2.6.22.7/kernel/drivers/md/faulty.ko:
    +/lib/modules/2.6.22.7/kernel/drivers/char/hw_random/rng-core.ko:
    +/lib/modules/2.6.22.7/kernel/drivers/usb/storage/usb-storage.ko:
    +/lib/modules/2.6.22.7/kernel/drivers/usb/gadget/g_ether.ko: /lib/modules/2.6.22.7/kernel/drivers/usb/gadget/marvell_udc.ko
    +/lib/modules/2.6.22.7/kernel/drivers/usb/gadget/g_serial.ko: /lib/modules/2.6.22.7/kernel/drivers/usb/gadget/marvell_udc.ko
    +/lib/modules/2.6.22.7/kernel/drivers/usb/gadget/marvell_udc.ko:
    +/lib/modules/2.6.22.7/kernel/drivers/usb/gadget/g_file_storage.ko: /lib/modules/2.6.22.7/kernel/drivers/usb/gadget/marvell_udc.ko
    +/lib/modules/2.6.22.7/kernel/drivers/usb/class/usblp.ko:
    +/lib/modules/2.6.22.7/kernel/net/appletalk/appletalk.ko: /lib/modules/2.6.22.7/kernel/net/802/psnap.ko /lib/modules/2.6.22.7/kernel/net/llc/llc.ko
    +/lib/modules/2.6.22.7/kernel/net/802/p8022.ko: /lib/modules/2.6.22.7/kernel/net/llc/llc.ko
    +/lib/modules/2.6.22.7/kernel/net/802/psnap.ko: /lib/modules/2.6.22.7/kernel/net/llc/llc.ko
    +/lib/modules/2.6.22.7/kernel/net/llc/llc.ko:
    +/lib/modules/2.6.22.7/kernel/net/sunrpc/sunrpc.ko:

    It seems that the NAS does not like local paths, and it needs absolute paths to the modules.
    Strange…
    ok, problem solved. I edited manually the original file, putting these two new line:

    /lib/modules/2.6.22.7/kernel/fs/nfsd/nfsd.ko: /lib/modules/2.6.22.7/kernel/fs/exportfs/exportfs.ko /lib/modules/2.6.22.7/kernel/fs/lockd/lockd.ko /lib/modules/2.6.22.7/kernel/net/sunrpc/sunrpc.ko

    /lib/modules/2.6.22.7/kernel/fs/exportfs/exportfs.ko:

    Testing:

    [root@nas ~]# lsmod
    Module Size Used by Not tainted
    usb_storage 68235 0
    xfs 605412 1
    [root@nas ~]# free
    total used free shared buffers
    Mem: 61952 60228 1724 0 828
    Swap: 128376 0 128376
    Total: 190328 60228 130100
    [root@nas ~]# modprobe -v nfsd
    Loading module sunrpc
    Loading module lockd
    Loading module exportfs
    Loading module nfsd
    [root@nas ~]# free
    total used free shared buffers
    Mem: 61952 59928 2024 0 928
    Swap: 128376 0 128376
    Total: 190328 59928 130400
    [root@Anime ~]# lsmod
    Module Size Used by Not tainted
    nfsd 97924 0
    exportfs 4512 1 nfsd
    lockd 68856 1 nfsd
    sunrpc 167892 2 nfsd,lockd
    usb_storage 68235 0
    xfs 605412 1

    Good, now i need to do some tweaking..
    Just for asking.. these file are really needed?
    modules.alias.bin
    modules.dep.bin
    modules.symbols.bin
    There are no *.bin in the orginal kernel..

    I did all these tests via ssh, my NAS is at home while i’m off-site student
    If something had gone seriously wrong, I could not fix the problem before this Easter ..

    04:21 AM… it’s late. I need to sleep. I will continue testing tomorrow.
    Anyway, thanks very much for your contribution. I really appreciate it. 🙂

  8. autostart nfsd service:
    we need to edit /etc/sysconfig/modules and insert nfsd after usb-storage line:

    # vi /etc/sysconfig/modules

    # Begin /etc/sysconfig/modules - Module auto-loading configuration.

    # The syntax of this file is as follows:
    # [ ...]
    #
    # Each module should be on it's own line, and any options that you want
    # passed to the module should follow it. The line deliminator is either
    # a space or a tab.

    xfs
    usb-storage
    nfsd

    # End /etc/sysconfig/modules

    and do ESC+wq for save the file.

    I have modified the modules archive: kernel_modules_2big_nfsd.tar.gz

    In the new archive there are only these files:

    /lib/modules/2.6.22.7/modules.alias
    /lib/modules/2.6.22.7/modules.ofmap
    /lib/modules/2.6.22.7/modules.inputmap
    /lib/modules/2.6.22.7/modules.isapnpmap
    /lib/modules/2.6.22.7/modules.usbmap
    /lib/modules/2.6.22.7/modules.ccwmap
    /lib/modules/2.6.22.7/modules.ieee1394map
    /lib/modules/2.6.22.7/modules.seriomap
    /lib/modules/2.6.22.7/modules.symbols
    /lib/modules/2.6.22.7/modules.pcimap
    /lib/modules/2.6.22.7/modules.dep
    /lib/modules/2.6.22.7/kernel/fs/exportfs/exportfs.ko
    /lib/modules/2.6.22.7/kernel/fs/lockd/lockd.ko
    /lib/modules/2.6.22.7/kernel/fs/nfsd/nfsd.ko
    /lib/modules/2.6.22.7/kernel/net/sunrpc/sunrpc.ko

    I have modified modules.dep with the full absolute path for every kernel module, and i have changed the files rights to root user.
    To install the files in the nas you just extract the archive:
    # tar -xvzf kernel_modules_2big_nfsd.tar.gz -C /
    Thanks again for your help Bert, if there is anything wrong with this procedure that I did let me know.
    The only problem I have and that I can test the nfsd until I return home.

  9. Hi,
    I wrote like this, but i’m french 🙂
    First, a big thanks for your blog post about telnet, it works very fine, and for this nfs archive too. I succesful load module :

    root@LaCie-2big:/www/cgi-bin/public# lsmod
    Module Size Used by Not tainted
    nfsd 97924 0
    exportfs 4512 1 nfsd
    lockd 69976 1 nfsd
    sunrpc 170452 2 nfsd,lockd
    usb_storage 68235 0
    xfs 605412 1

    But now I don’t know how to mount a share folder on my desktop. I guess it’s like this : # mount -t nfs 192.168.0.30:/home/share/ /media/lacie/
    But I don’t know the 2big path, and maybe we first do export nfs share on 2big ?

    Thanks for your help.
    Best regards
    Sylvain

I commenti sono chiusi.