From NAS-Central Buffalo - The Linkstation Wiki
Scott by any means please post your kernel modules, as I was able to produce modules that allow me to mount an nfs export, but when I try to do any operation over them this mount gets stuck. And if you can, please include your .config with the modules.
--Yvasilev 19:23, 18 Aug 2005 (CEST)
Just downloaded European 2.00 firmware. Extracted, added Dropbear and NFS like described in this Wiki. The ~var symlink was not overwritten when extracted using the same tar command as suggested for Dropbear. Still, one could always extract with -w as well, do not extract the /var stuff, but extract it to another folder later on and move it manually. Re-compressed, installed new firmware. File system still there without problems. Only remaining problem:
- admin@TERASTATION:/etc$ /etc/init.d/nfs-common start
- /etc/init.d/nfs-common: modprobe: command not found
- Starting NFS common utilities: statd/etc/init.d/nfs-common: start-stop-daemon: command not found
Therefore on client side:
- [root@linuxbox ~]# mount 192.168.13.8:/mnt/array1 /mnt/terabackup/
- mount to NFS server '192.168.13.8' failed.
Two additional comments:
- after extracting the NFS stuff, etc/exports needs to be edited. The default exports only to 192.168.1.1, but you probably want to adjust it to export to either your box (change IP there) or your whole network (/mnt/array1 192.168.1.0/255.255.255.0(rw,root_squash) or similar).
- You need to edit linkstation_version.txt to show a newer version number, otherwise you won't be able to upgrade. (Or add /force to the NASUpdater.exe command line)
I tried this twice. After the first time, I had to reinitialize the drives in order to restore the file system so that I could boot. This, the second time, I poked around the file system a little more and realized untarring it, using tar xvzf all-nfsd.tar.gz, overwrote my /var directory. It was overwritten because I *think* it was a symlink to /mnt/ram/var [http:/ls-lR/1.04/ file list]. I can't be certain because I'm running 1.12, but recreating the link seems better - I see the expected stuff in /var (e.g. /var/log/messages). I have no idea if the file system is normal because I haven't rebooted.
Anyone have any input? Is there a way for tar not to clobber that link?
I started up the portmapper and nfs, but I can't mount:
[root@mymachine ~]# mkdir -p /mnt/terastation/array1 [root@mymachine ~]# mount -t nfs 192.168.11.150:/mnt/array1 /mnt/terastation/array1 Segmentation fault
- nmap shows nfs and rpcbind are up.
- mymachine, running Fedora Core 4, nfs mounts stuff from an NSLU2 running Unslung 5.5 w/o issues.
- showmount -e 192.168.11.150 shows the export
Does anyone have any ideas of what else I can try? TIA
--Bluefedora 14:40, 27 Nov 2005 (CET)
One issue is that /var/lib/nfs/rmtab is a directory instead of a file. If you look in the syslog, you will see a message like:
Feb 11 20:21:01 terastation rpc.mountd: could not open /var/lib/nfs/rmtab for locking
Unfortunately, this does not fix the problem. even after a reboot, mount request still segfault.
However, now it appears to work by examining the terastation syslog:
Feb 11 22:29:55 terastation rpc.mountd: authenticated mount request from client:616 for /mnt/array1 (/mnt/array1)
There are no other errors. This makes me wonder if there is a compatibility issue with the NFS version on my FC4 box and the one installed from sf.net.???
--cctjon Sat Feb 11 22:33:29 MST 2006
I think individual problems and requests for help belong into the discussion part, not into the article! CCRDude 13:37, 13 Feb 2006 (CET)
I had this problem - it isn't the terastation that causes the the seg fault. Update your util-linux package on your nfs client via yum (yum -y update util-linux), and the problem disappears. It's a bug in mount, which is fixed in the latest version. --Robert 00:13, 20 January 2007 (CET)
User Space NFS Daemons
I just spent the day hacking my Terastation Pro to support NFS. While it works perfectly now it was such a pain I felt I should post my solution here to save others some suffering.
First off don't bother with the kernel space version of NFS. I tried the posted modules in the articles section, all-nfsd.tar.gz, and they were nothing but trouble. The Terastation Pro kernel is a different build of the same 2.4.20 kernel used in the original Terastation, so the kernel symbol table is slightly different. As such the modules will not load easily.
No big deal right? We know the symbols are still there, the names simply changed a little bit. Just modify the symbol names in the old modules to reflect the new symbol names, all the information you need is in /proc/ksyms. I did this and I was able to load the modules, start the NFS server, and even mount an exported filesystem. Unfortunately, there seems to be a problem, the nfsd threads on the Terastation will die when handling getattr RPCs. That's just no good, don't bother with this approach there are easier ways.
Terasation: 2.4.20_mvl31-ppc_linkstation Terastation Pro: 2.4.20_mvl31-ppc_terastation
Next I opted to try the user space NFS daemon approach. After some experimentation I settled on the pre-packaged ppc version debian shipped some time back. Don't go with the version SuSE shipped it seg faults as as soon as a client mounts. Since it was a pain to round up a working ppc version of all these binary here's a pre-packaged tarball of everything you'll need to get NFS working on a Terastation Pro. These binaries should work fine on an original Terastation as well but I have not been able to test that.
Just untar this in to the root of your Terastation, configure your /etc/exports file, and start the service with the init script.
cd / wget http://www.undeadscientist.com/terastation/nfs-terastation-pro.tgz tar -xzvf nfs-terastation-pro.tgz vi /etc/exports /etc/init.d/nfs-user-server start
Then just mount it on whatever clients you see fit. There was one client side issue I ran in to which is worth mentioning, and that is you may need to explicity mount it as an NFS V2 client. This is due to an issue with the debian build of the user space NFS daemons.
mount -o nfsvers=2 -t nfs 192.168.1.5:/mnt/array1 /mnt
--Abarrow 16:29, 10 May 2006 (CEST) Thanks for the instructions! I also tried to kernel space version on my original Terastation with no luck. I then followed your instructions, and it worked a treat. So, I can confirm that the user space version of NFS works fine on an original Terastation.
--Entropy The user-land nfs referenced above has a 2Gb file size limit because it only speaks the v2 protocol.
I just finish setting this up and it seems to be working, at least nfs service started and if I scan the machine, looks like portmapper, nfs and mountd are running, but I can not get mount to work. I get an access denied when I try to mount. (I am mounting from a Solaris Box- Solaris 9)
Here's a snippet: root@AMS-2811:/# mount -o nfsvers=2 10.24.6.155:/test /test mount: 10.24.6.155:/test on /test - WARNING unknown option "nfsvers=2" nfs mount: 10.24.6.155:/test: access denied root@AMS-2811:/#
-- Kimbotha 15:05, 25 October 2006 (CEST): Changed link as linkstationwiki.org link seemed broken. Yes I am interested in having a cross toolchain for the Terastation. Am going to try and build one for myself if I can.
-- johnsalomon 14:14 04 February 2009 (CET): If you're running the user-space NFS package, and are getting RPC time-outs when mounting a drive from the client, try putting the client's hostname in the NAS' /etc/hosts file.