I'm having some trouble in trying to make a clean solution and tougher time searching to not get the basic mounting pages/posts. So I thought I'd throw this out here.

For Oracle, we have an app server that runs /sharedapps and is an NFS mount for all other app/db nodes. What I'm working on now is that on this app server that hosts/exports /sharedapps file system has a sub folder with a CIFS mount (/sharedapps/data/appmount). The thing is that the remote nodes with the NFS mount to /sharedapps don't see the remote data in /sharedapps/data/appmount, only the main app server that has the CIFS connection. Realistically it makes sense why, but I'm trying to research if there is a way to have it do so. This is where I'm struggling.

We are working on this in a dev instance right now but soon to be in production. In production, there are many DB nodes that could process a request which is why it would be best to have the NFS connection follow the remote CIFS connection.

Thanks for your input.

First of all, what OS are you running?

Can you be a bit clearer on what dirs are NFS, and what dirs are CIFS.

Perhaps, post your /etc/exports file?

This is just an idea based on something simalar I have done in the past, I have no idea how CIFS will work mounting inside a NFS mounted directory but it sounds like you will have to do a hierarchical mount.

So of course first mount your /sharedapps on the client then mount the CIFS share inside it:

mount -t cifs //server-name/share-name /sharedapps/data/appmount -o username=shareuser,password=sharepassword,domain=nixcraft

Best thing I can think of - I dont use CIFS though so it may not work

Sorry, yes, should have been more on environment stuff.

app server:
RHEL 4.8.

exports file:
/sharedapps FQDN4DBnode(rw,sync,no_root_squash)

CIFS- mount -t cifs //windows2003server/share$ -o username=user,password="pass" /sharedapps/data/appmount

DB server:
RHEL 5.4.

fstab file:
FQDN4appnode:/sharedapps /sharedapps nfs rw,hard,bg,proto=tcp,rsize=32768,wsize=32768,noac 0 0


On the app node, I can view the data on /sharedapps/data/appmount through the CIFS connection. The DB node, when navigating through NFS to /sharedapps/data/appmount it doesn't see the data through CIFS connection. I feel that it's the app node making the CIFS connection request to get the data when locally requested. But when the DB node does it, it' not linking to the CIFS connection to get a view of the data on that connection. Sorta to say, the app node will request the data when he knows of a need, but he doesn't know when an NFS connected device is wanting to see it. The app node would (for lack of better term) proxy the request for the mount point (/sharedapps/data/appmount) when requested to be viewed by the NFS connected node.

I have a feeling that it's not possible, but I wanted to make a post to see if someone that is more root'ed in the cores of Linux would have any insights to it. A few that I have talked to, scratch their heads and say "good luck with that ..." Large community is better than a few colleges ..

Hope this info is helpful.

If(!) I understand correctly, you have a W2k3 server that shares out a dir.
The App Server mounts the W2k3 dir via cifs.
It then exports dir that via nfs

The DB server tries to mount/access the dir on the App Server, using nfs...

I think the 2 FS types are going to clash; how would it handle locking? cifs & nfs don't talk to each other..

Why can't both RHEL systems just mount from W2k3 directly, via cifs (as app server already does)?

I agree, they don't talk together. Spent many hours researching if through the NFS mount, the CIFS request could be processed by the app node. I haven't found anything, an option in the man pages or any attempt to tweak myself. That's why I wanted to post it out to see if someone had the insights to it. There are many better Linux folks out there than me, converted to Linux just a couple of years ago, not seasoned enough yet ...

Yes, they could. In production, several nodes (both app and DB, 7 all together) rely on the /sharedapps NFS link to process and share data. Any app or DB node can run a request and handle information from this data. That's why it's optimal if this could work. Right now working on processing through an FTP package in the DB tier so that they can independently process and set the files in the /sharedapps volume. But I still like the discussion and hopeful to gain additional knowledge through community discussion.

Thanks !

This looks like you are trying to share a child of the main shared filesystem. By default, NFSv3 will not automatically export the contents of the child with its parent. Solution is to use the crossmnt option for the parent, or nohide option on the child.

Your /etc/exports file should look like this...
or
This *may* work. No guarantees though :-)
Let me know if it does.

i don't see why mikey's solution wouldn't work
mount points are directories, nothing more, nothing less, a device can be mounted anywhere in the tree regardless of what the filesystem in which the mount point resides, the only caveat is the parent filesystem has to be mounted first to ensure the mount point exists

First of all, thank you mikey99. I ran through some initial settings but it wasn't as fluent as I'd like. I'm sure I'm missing something. Browsing from the DB node was slow when it started to hit the sub-folders. I'm sure it's just something in me getting the right method into the configs.

Frieza, thanks for the additional note. And the signature. Musical reference speaks out, being a musician ... Fast becoming an ex-windoze person ...

I'm going to run it through my dev boxes and run the settings. Thanks much to everyone for contributing. My failure was the manz on exports. I focused on the mount options. Being crazy days and all, I hope to get the time in this week and make a note on it. But feeling good about it, just need to tinker without having impacts to the projects running on the actual dev boxes.

Take care ..