NFSd used with SymLinks?

[CentralWare]

I have two hard drives (200G=>SDC1 and 320G=>SDB1 labeled accordingly)
On the 320G drive I tried to mount it as /mnt/320G (which goes through fine)
From there, I link the directory /mnt/320G/nfs to /nfs (ln -s /mnt/320G/nfs /nfs)

* It's just a guess, but I'm thinking the link /nfs is owned by root:root instead of *:staff which MAY be an issue with NFS???  I haven't tried to readjust yet as this is all being done at boot(sync)

On a client machine (TC) I try to mount this in the boot code as nfsmount=server:/nfs and it silently fails.
Once at the shell I try to sudo mount /mnt/nfs and I'm given
  mount server:/nfs failed, reason givel by server: Permission denied
  mounting server:/nfs on /mnt/nfs failed: Bad file descriptor
(scratches one's head - there's nothing in /var/log/messages to give a hint.)

Now, if I mount the entire drive on the server to /nfs everything goes through just fine on the client. (This isn't practical for what's needing to be done, though.)  I also tried mount -o nolock but it complains that it doesn't understand nolock (I had that problem before with the same permission issue.)

Anyone have an idea as to how nfs-server would be willing to follow a link (off the root path) instead of mounting the drive itself there?

I'm down to this in /etc/exports: /nfs *(rw,insecure,sync,no_subtree_check,no_root_squash)

Thanks for your time!

[curaga]

Try a bind mount instead of symlink.

mkdir /nfs
mount --bind /mnt/320G/nfs /nfs

[CentralWare]

@curaga: Sadly...  exact same outcome.
(I deleted the links, manually created the directory /nfs, the mount went through fine...  client side has the same issue.  I reset ownership to tc.staff and root.staff to no avail as I'm unsure what top-level permissions NFSd expects.)

[CentralWare]

Thus far everything looks A-OK from what I can tell...  except...

exportfs -ra
exportfs: Warning: /nfs requires fsid= for NFS export
exportfs: /proc/fs/nfs/exports:1: unknown keyword "test-client-(rw"

fsid=root was added to /etc/exports which takes care of the first issue
The second line I Think is a self-test bug in nfs-utils

Regardless...  client is still getting the boot.  (I tried mounting on the server itself - same response.)

[curaga]

fsid=root is a NFSv4 option. Could also try to force v3. Anyway, no sense testing with a client until you can mount locally on the server.

[CentralWare]

After exhaustive research on the topic (ie: "cross-mounting" with NFS) I believe I've come up with a solid theory as to why this isn't working...  which will be tested here shortly once I've un-done the damage from experimenting.

Pieces involved:
NFS inherent security
Exports
Manual pages being a bit misleading

The excerpt is as follows:

Code: [Select]

crossmnt: This option is similar to nohide but it makes it possible for clients to move from the filesystem marked with crossmnt
to exported filesystems mounted on it. Thus when a child filesystem "B" is mounted on a parent "A", setting crossmnt on "A"
has the same effect as setting "nohide" on B.

This makes one assume that in /etc/exports, if I were to set /nfs as an exported file system and use crossmnt as an option, all "child" file systems will follow in turn.  The catch here is that /nfs itself is being bound AS a child (IMO) which is likely the cause for the permission issues.

After removing the mounted filesystem, /nfs is accessible (server AND client side) so my permissions set on /nfs itself seem to be good.
I can't see myself launching the root directory ( / ) as a PARENT, so the CHILD has "issues" so to speak of following the exportfs command.  (Again, in theory.)
My next test is to mount the hard drives in directories UNDER /nfs and see if this works.  I'm expecting the same permission errors even though crossmnt is being noted in the options.
What I expect will work is:
/nfs (empty) being set in exports with cross-mount.
/nfs/mnt1 (mount --bind or directly mounted) AND an additional export listing for /nfs/mnt1 with "nohide"
/nfs/mnt2 (mount --bind or directly mounted) AND an additional export listing for /nfs/mnt2 with "nohide"
* I'm thinking that if done in this fashion, even SymLinks "should" work as expected with NFSd

Based on the documentation, it sounds as those extra export entries are not supposed to be necessary, but based on experimentation it seems as though they're going to.  (Any other experiences out there would be appreciated!)

[CentralWare]

CONCEPT FAILURE

Using the existing nfs-utils (TCL 4.x+) for both client and server simply do not work together with the option crossmnt as described.

Scenario:

Code: [Select]

mkdir /exports
exportfs -o rw,insecure,all_squash,anonuid=65534,anongid=65534,fsid=0 *:/exports
Works as it's the "parent" file system

Code: [Select]

mkdir /exports/drive1
mount /dev/sdb1 /exports/drive1
exportfs -o rw,insecure,all_squash,crossmnt,anonuid=65534,anongid=65534,fsid=0 *:/exports/drive1
Fails to be READ as a CHILD to /exports

When mounting server:/exports you'll SEE "drive1" as a directory...  but it's empty.

Code: [Select]

mkdir /mount/path/exports/drive1
mount server:/exports/drive1 /mount/path/exports/drive1
Works (in addition to the above mount) though it defeats the concept of crossmnt.
Now, based on how tc-config works, there's only one boot code for nfsmount= permitted, the above scenario requiring two.  For my needs, I'll remaster TC and build up the functions to allow multiple nfsmount=[something] to be allowed within the boot string (plus updating it to allow destination path to be specified) but for the average Joe this is likely to pose issues with stacked exports such as this (and PXE booting, which is my case)

[gerald_clark]

The nfsmount boot code is intended just to get you a tce directory.
Once you have finished booting, you can add additional mounts to your bootlocal.sh.