NFS on the NSLU2
- Greetings all.
One thing I noted over the w/e playing around with this thing, since
I was planning eventually to access it via NFS (Jim Buzbee has
provided info on this).
It appears that all shares created are under uid/gid 501/502. When
you create a new user, uid/gid assignment starts at 2000, but these
users do not own their own shares.
Access control is handled through samba via read and write lists
instead of throught the standard unix protection scheme.
From one standpoint, this makes sense, because it does make it a lot
easier for samba to ensure that it can always deliver files if they
all share the same uid/gid/protection mask, but obviously it doesn't
work properly for nfs.
I haven't (yet) tried changing file ownerships on the shares to see
The only problem is that assigning uid/gids starting at 2000
conflicts with the way that most linux/unix basis systems work. FOr
instance, MacOSX starts assigning at 500. If I recall correctly, my
gentoo based linux system started at 1000. I don't recall what debian
did, but I DO recall having to change uids and gids on my linux-based
file server when I moved from debian to gentoo. This is going to be a
pain to deal with...I thought of moving the two linksys created
accounts to 401 and 402, and changing the users to start at 500 to be
compatible with my Mac (main workstation) and gentoo boxen, but that
will probably break if I install new firmware, so that's not the best
I am not aware that nfs supports a per-uid mapping syntax - so you
can use root_squash, anon_uid, etc, but you cannot, as far as I know,
specify that an nfs request from a remote user with for instance uid
500 be mapped locally to uid 2000, so you need to get the uids to
match between systems.
Another samba note: If you've looked at /share/smb.conf to see the
active samba config, you'll note that the write list for each share
includes the administrative group and the group of the user owning
that share, eg for user 'nl':
write list = @"administrators", @"nl"
Interestingly, the "@" sign indicates that the following string
should be interpreted first as an NIS group and then as a unix group,
in contrast to the +group syntax, where the + indicates that it is
just a unix group. I wonder if that means that there are hooks for
NIS in this box, or was this just an unintentional syntax choice?
Lastly, I through out a complete kludge for those working on getting
various scripts to run at startup on this box. While I share the
desire eventually to modify the config database and/or firmware as
necessary to automatically start up scripts for nfs, etc (I'm hoping
one day to be running nfs, squid, fetchmail, and courier-imap on this
thing and replace my current server with a totally noiseless
solution!) there is a way to kludge this process for now.
Using the samba "magic script" syntax, you can specify the name of a
script that, when uploaded to a samba server, is automatically run
and then deleted. You can create a script on another system on your
network, and run a cron job to periodically copy that file to the
samba server, where it will be executed. Said script can check to see
if the proper daemons are running (nfs, etc) and if not, restart them.
Not very elegant, but it does automate getting scripts running for
the short term. I haven't tried this yet, since I don't really have
the need for this until I have all of the above programs set up, but
it's an idea.
- --- In firstname.lastname@example.org, "joule360" <joule360@y...> wrote:
> I am not aware that nfs supports a per-uid mapping syntax - so you
> can use root_squash, anon_uid, etc, but you cannot, as far as I
> specify that an nfs request from a remote user with for instanceuid
> 500 be mapped locally to uid 2000, so you need to get the uids toI got this working on my NLSU2 this weekend. I've got this in my
> match between systems.
/share/ 192.168.11.2 (rw,insecure,map_static=/etc/nfsusermap)
And my nfsusermap contains this, for use with my single-account OS X
uid 501 2000
gid 20 501
I haven't added a second client machine yet, but when I do I guess
it'll simply get its own
userid map file.
Of course, I added symbolic linking of /etc/nfsusermap to startNFS.sh.
- --- In email@example.com, "James Funkhouser" <fantalbert@y...> wrote:
> --- In firstname.lastname@example.org, "joule360" <joule360@y...> wrote:That's great - I have never seen the map_static syntax before! It does not appear in "man
> > I am not aware that nfs supports a per-uid mapping syntax - so you
> > can use root_squash, anon_uid, etc, but you cannot, as far as I
> > specify that an nfs request from a remote user with for instance
> > 500 be mapped locally to uid 2000, so you need to get the uids to
> > match between systems.
> I got this working on my NLSU2 this weekend. I've got this in my
> exports file:
> /share/ 192.168.11.2 (rw,insecure,map_static=/etc/nfsusermap)
> And my nfsusermap contains this, for use with my single-account OS X
> uid 501 2000
> gid 20 501
> I haven't added a second client machine yet, but when I do I guess
> it'll simply get its own
> userid map file.
> Of course, I added symbolic linking of /etc/nfsusermap to startNFS.sh.
exports." Where can I read about this?
Although I'm not sure at this point there is a downside to just modifying all of my
accounts so the uids / gids match that of my OSX accounts, since I don't plan to use the
linksys web pages for any account creation at this point.