FW 2.00.01: NFS handling badly broken!

[omega]

Inspired by the post from user chriss I've checked on my N5200 with FW 2.00.01 if NFS is working for me... and it is NOT working

So I've checked what's going on and I've found out, that the script /app/bin/rc/nfs is heavily broken. It creates and invalid /etc/exports file and therefore the NFS daemon refuses to start. This is the answer why several users are not able to access NFS anymore.

The buggy code in /app/bin/rc/nfs was added recently as this code isn't available in FW 1.00.08 and 1.00.10. Each time the NFS daemon is started the file /etc/exports is created from scratch (the old version is removed, so my NFSEXPORT module doesn't work anymore ) with the folder information from the database.

BTW the coding of this script is really really bad - it seems like somebody is starting to learn how to write shell scripts

The bad news is that at the moment I don't know any workaround. So anybody who needs NFS shares shouldn't update to 2.00.01.

thecus: please fix this bug immediately, I cannot access my NFS shares anymore!!!

Andreas

[gideon007]

you should apply for a part time job at Thecus, really. And you could sent in your application with some superior scripts only.
"this is what you've got! And this is 2hat you can expect from my knowledge!"

We are lucky to have someone like you around in this forum. BUT is Thecus reading these posts by you? I sure hope so, but I doubt it

[omega]

Thanks for your nice words....

BUT is Thecus reading these posts by you? I sure hope so, but I doubt it

I know that Thecus (at least sometimes) is watching this forum

But until now they're drawing the right conclusion of what I'm and other users are telling them. I'll never understand why companies are so ignorant..... when they are lucky enough to have motivated (and somehow nuts) customers trying to test and improve their product.
Sorry, maybe I'm going OT now....

Andreas

[omega]

thecus:

I really need the NFS functionality asap.

The function nfs_exports() in /app/bin/rc/nfs is the culprit. Maybe I can speed up the bug fixing by providing a better and working nfs_exports() function. Feel free to use it - it's in the public domain and I'll not claim any rights

I've tested the code and it is working.


#!/bin/sh

sqlite=/opt/bin/sqlite
confdb=/app/cfg/conf.db
nfs_tmp=/tmp/exports
default_setting="sync,anonuid=99,anongid=99"

set_nfs_exports() {
   > "$nfs_tmp"

   master_raid=
   
   for raid in $(cd / ; /bin/ls -d raid[0-9]* 2>/dev/null) ; do
       raid_db="/$raid/sys/raid.db"
       ismaster=$($sqlite $raid_db "select v from conf where k='raid_master'")
       
       if [ "$ismaster" == "1" ] ; then
           master_raid=$raid
           sqlcmd="select * from nfs"
       else
           sqlcmd="select * from nfs where share!='nsync' and share!='snapshot' and share!='usbhdd' and share!='usbcopy'"
       fi
       
       "$sqlite" "$raid_db" "$sqlcmd" | while read spec ; do
           set -o noglob ; OIFS=$IFS ; IFS='|' ; set $spec "" ; IFS=$OIFS ; set +o noglob
           share=$1 ; hostname=$2 ; privilege=$3 ; rootaccess=$4
           echo "\"/$raid/data/$share\" $hostname($privilege,$rootaccess,$default_setting)" >> "$nfs_tmp"
       done
   done

   if [ -n "$master_raid" ] ; then
       raid_num=$(expr match "$master_raid" '[^0-9]*\([0-9]*\)')
       raid_dev=$(awk '$2 == "'/$master_raid/sys'" { print $1 }' < /proc/mounts)
       
       if [ "$raid_dev" == "/dev/vg$raid_num/syslv" ] ; then
           /bin/cp "$nfs_tmp" "/$master_raid/sys/exports"
       fi
   
       ln -sf /raid/sys/exports /etc/exports
   fi
   
   rm -f "$nfs_tmp"
}


Andreas

[omegahelix]

Thanks Andreas, that works. Do you know how I can permanently modify the /app/bin/rc/nfs script? It tells me it's on a read-only filesystem (/dev/hda5).

[omega]

You cannot edit the nfs script.... you already told the reason: it is located in a read-only filesystem.

The IMGDUP module would help here - but now that BETA FW 2.00.03 is out and the problem is fixed there, I see no need to do any magic here.

Although I'm quite sure that the new BETA firmware should work there is always a small risk using BETA FW.

Andreas

[jetjockey]

Errrr.

Is NFS broken in FW 2.00.00.11? Thats the FW that allows the 5200 to use iSCSI?

Jet.

P.S. What are the implications of NFS being broken

[glo8al]

jetjockey said:

Errrr.

Is NFS broken in FW 2.00.00.11? Thats the FW that allows the 5200 to use iSCSI?

Jet.

P.S. What are the implications of NFS being broken

If you don't use NFS, nothing.
If you use NFS I think you can only do one share as I believe the BUG happens with more than one NFS share.

[christug]

Hi,
I had created a second NFS share and since then, original one no longer works, "mount: raid:/raid0/data/Major failed, reason given by server: Permission denied"

have since deleted second NFS share but still have this problem, what can I do to fix this ?

(If this is a bug) Do these bugs get listed anywhere ?

thanks,

Chris

[trekman]

I sort of fixed the issue using the same workaround to "modify read-only scripts" as in my solution to use multiple iSCSI targets per RAID (described in some other thread).

The basic idea is to copy the modified scripts to the /var folder each time the N5200 is powered on and to execute them manually from there once.
This sounds tedious, but usually you do not power your NAS up and down all the time.
A simple Reboot while keeping power up does not delete the volatile "tmpfs" that holds the /var folder and therefore the scripts remain available.
Depending on which scripts you modified you might have to run them manually after each Reboot though.

You could probably put the modified scripts onto a configured raid volume and run them from there....but I prefer to keep them on my PC and copy them into /var, because this makes them independent from formatted disks, so they are available also if I would have to rebuild the raids from scratch.....

So this is what I did to get multiple NFS shares with a correct /etc/exports in FW 2.00.01 :

1) installed the SSHD module (described in other posts)
2) copied the NFS script "/app/bin/rc/nfs" to my PC
3) in the copied script replaced the nfs_exports() function and the declarations with omega/Andreas' code posted above
4) copied the modified script back into /var
5) chmod 777 /var/nfs
6) called the script with "/var/nfs restart"

Steps 4-6 I will have to do after each power-up.
I did not soft-reset the N5200 yet after applying this workaround, so I do not know if step 6) is necessary after a Reboot.

Just a workaround - but I can live with that until a real fix in a new firmware is available.

Edit: did not check for 2.00.03 yet.....apparently NFS works in .03 ?
What about the SSHD module ? I need that for my iSCSI workaround, so maybe I need to stay on .01 for now ?

[peterfu]

NFS works fine with FW 2.00.04. Modules are also working with FW 2.00.04 - don't use FW 2.00.03 as the module handling is broken in this version.
br
Peter

[trekman]

peterfu said:

NFS works fine with FW 2.00.04. Modules are also working with FW 2.00.04

Considering how many people end up with dead boxes shortly after upgrading to 2.00.04 I hesitate to upgrade.....I guess I stay with .01 and my scripts : "never change a running system"

[hanstor]

Say - does anybody know how to clean up the faulty exports? I mean - my exports-file is generated with faulty folder information. Long gone folders still appear in my exports, and at least I do not know how to get rid of these old listings...

"/raid0/data/" ned(,,sync,anonuid=99,anongid=99)
"/raid0/data/DVDRip" 192.168.1.0/24(ro,no_root_squash,sync,anonuid=99,anongid=99)

The top most line is probably from a still existing folder, but which has another name - and the complete name is not included in the quotes anyway.

The bottom folder is deleted ages ago...

If I have understood this post, I might try to edit the nfs-script, and use IMGDUP, and will do so, but the optimal solution would of course be to get rid of these to erranous listings...

Any ideas, anyone?

Suppose it's fair to mention: Firmware Version 2.01.10.17

-------------

Edit:

Solved my own problem...

As mentioned, the listings where wrong. Specificly in /raid0/sys/raid.db.

This is a SQLite 2.1 db, which I edited in SQLite Database Browser 1.1, this one is able to edit 2.1 db. Put it back, and voila!!!

Great start on 2010! ;D