LaCie 2Big Network: supporto nfs

Pubblicato il 22 Ottobre 2010 da Steppenwolf

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:

portmap_6.0-9_armel.tar.gz (10,6Kb)
unfs3_0.9.21_armel.tar.gz (38,2Kb)

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”

tinti il 25 Ottobre 2010 alle 19:10 scrive:

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

Keep going on this good work.
Steppenwolf il 28 Ottobre 2010 alle 10:55 scrive:

You are welcome! 🙂
xdma il 10 Dicembre 2011 alle 17:34 scrive:

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.
Steppenwolf il 11 Dicembre 2011 alle 11:42 scrive:

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.
xdma il 11 Dicembre 2011 alle 17:17 scrive:

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).
Steppenwolf il 12 Dicembre 2011 alle 11:57 scrive:

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à 🙂
Bert il 3 Febbraio 2012 alle 18:00 scrive:

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
Steppenwolf il 4 Febbraio 2012 alle 04:25 scrive:

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. 🙂
Steppenwolf il 5 Febbraio 2012 alle 15:25 scrive:

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.
Sylvain il 18 Febbraio 2012 alle 14:48 scrive:

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.

Aggiornamento / Update (05/02/2012):

Rsync

Related posts:

10 pensieri su “LaCie 2Big Network: supporto nfs”