NFS Woes

[kalberga]

I keep running up against a wall with NFS and can't find anything on the forums to address the problem.

I have 2 machines, a desktop (gateway-5648) running Ubuntu jaunty and a laptop (dv5z) running Kubuntu Jaunty.

On gateway-5648 I have 3 directories in /srv, named 1,2 and 3. Each is a mounted partition on one of 2 harddrives.

I exported /srv in NFS. When I try and mount it on dv5z the mount is successful and ls shows the three subdirectores (1,2,3) but when I ls any of those subdirectories they show as empty, even though they all have files in them.

Can anyone explain what is happening?? and as important, how to fiz it?

Thanks!!!!!

[dibl]

Re: NFS Woes

This looks like good guidance:

http://littlegirl.hostrator.com/NFSHowTo.html

[kalberga]

Re: NFS Woes

I went through Little Girl's tutorial a second time with the same result.

Again I can see the first level subdirectories in the "share" but nothing in any of those directories or anything below them. I also put a file in the first level directory and it was visible over the network.

Is there something with UMASK or something else that I need to do on the server end? I had chmod all files in the server side to 777.

Thanks again!!

[Little Girl]

Re: NFS Woes

I went through Little Girl's tutorial a second time with the same result.

Again I can see the first level subdirectories in the "share" but nothing in any of those directories or anything below them. I also put a file in the first level directory and it was visible over the network.

It's probably because /srv is owned by root. I've never exported a directory owned by root. In looking through the exports man page, I suspect that the root_squash part of the /etc/exports line is the culprit:

Here’s the complete list of mapping options:

root_squash
Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be
equally sensitive, such as user bin or group staff.

no_root_squash
Turn off root squashing. This option is mainly useful for diskless clients.

all_squash
Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc.
The opposite option is no_all_squash, which is the default setting.

anonuid and anongid
These options explicitly set the uid and gid of the anonymous account. This option is primarily useful for PC/NFS clients,
where you might want all requests appear to be from one user. As an example, consider the export entry for /home/joe in the
example section below, which maps all requests to uid 150 (which is supposedly that of user joe).

EXAMPLE
# sample /etc/exports file
/ master(rw) trusty(rw,no_root_squash)
/projects proj*.local.domain(rw)
/usr *.local.domain(ro) @trusted(rw)
/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
/pub (ro,insecure,all_squash)
/srv/www -sync,rw server @trusted @external(ro)

The first line exports the entire filesystem to machines master and trusty. In addition to write access, all uid squashing is
turned off for host trusty. The second and third entry show examples for wildcard hostnames and netgroups (this is the entry
‘@trusted’). The fourth line shows the entry for the PC/NFS client discussed above. Line 5 exports the public FTP directory to
every host in the world, executing all requests under the nobody account. The insecure option in this entry also allows clients
with NFS implementations that don’t use a reserved port for NFS. The sixth line exports a directory read-write to the machine
’server’ as well as the ‘@trusted’ netgroup, and read-only to netgroup ‘@external’, all three mounts with the ‘sync’ option
enabled.

You might want to try changing that to no_root_squash and see if that solves it. And don't forget to restart everything after editing the file so NFS knows about the change.

If it works, let me know and I'll add that information to my guide.

[kalberga]

Re: NFS Woes

Thanks! I'm on the road now, but will try your suggestion when I get back home on Wed afternoon. Will report back my experience then.

Thanks!

[Little Girl]

Re: NFS Woes

Thanks! I'm on the road now, but will try your suggestion when I get back home on Wed afternoon. Will report back my experience then.

So how did it go? Hopefully it worked.

[kalberga]

Re: NFS Woes

Sorry about the delay!!

So here is what I found out...

Basically I am having the same issue after I tried your suggested change.

However, I believe that I found the culpret. On my desktop, I have three subdirectories under /srv (the directory I want to export) - 1,2, and 3. Each directory is actually a separate mounted partition on a 1TB hard drive.

Now, if I change the export from /srv to /srv/1 everything works perfectly. So I think there must be some issue with the fstab in the desktop machine that is not allowing the files in the mount to be seen on a remote computer.

Does that make sense to you? Are there other possibilities I may have overlooked, and if so what can I do to fix it??

FYI, attached is the fstab from the desktop machine....

Thanks for any (more) help you'd be willing to give....

--Kris


//gateway-5648/etc/fstab

# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/sda8 during installation
UUID=71c152f0-1a76-48db-8373-52e3f795c44d / ext3 relatime,errors=remount-ro 0 1
# /home was on /dev/sda7 during installation
UUID=87bae3f9-5186-431a-ba6d-eca0c48871e5 /home ext3 relatime 0 2
# /mnt/windows was on /dev/sda1 during installation
UUID=661F4C6D06CC06B9 /mnt/windows ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# /srv/files was on /dev/sda5 during installation
UUID=AA74979174975EBF /srv/files ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# swap was on /dev/sda6 during installation
UUID=c62075ed-6672-442f-bf81-8c4c5e91e65b none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
#
192.168.10.200:/srv/1 /srv/gateway-5648 nfs rw,hard,intr,noexec 0 0
# 192.168.10.200:/media/INO250GB-USB /media/INO250GB-USB nfs user,intr 0 0
# //192.168.10.200/server /srv/gateway-5648 smbfs auto,user 0 0
# sshfs#kris@#####.no-ip.org:/srv /srv/gateway-5648 fuse user 0 0

[Little Girl]

Re: NFS Woes

The way I look at it:

• The /etc/fstab file tells me who wants to share what with me.
• The /etc/exports file tells me what I want to share with whom.

I get the impression that the problem is with the /etc/exports file on the remote machine.

The first three parts (as far as NFS is concerned) of the entry in your /etc/fstab file want to know which machine wants to share which of its folders with which folder on your machine. So if we look at your fstab entry:

192.168.10.200:/srv/1 /srv/gateway-5648 nfs rw,hard,intr,noexec 0 0

It reads this way:

The machine at this address shares this folder from its machine with this folder on my machine

So if the machine at 192.168.10.200 doesn't want to share its /srv/1 folder with the machine that has that entry in its /etc/fstab file, then the entry has to be changed.

What does the /etc/exports file look like on both machines? The /etc/exports file breaks down this way:

I want to share this folder from my machine with the machine at this address using these options.

Example:

/sharedfolder 192.168.10.200(rw,no_root_squash,sync,no_subtree_check)

[kalberga]

Re: NFS Woes

Let me start with a clean slate, as I am getting myself confused here, and probably not communicating as well to you as I bleieve I already understood and implemented what you just sent...

My goal: Mount the directory /srv from a remote machine (gateway-5648) on a local laptop (dv5z). The remote directory has three subdirectories (named 1, 2 and 3) which are each separate partitions on the remote machine.

What I have now:

Set up /etc/exports on remote machine to allow for sharing:
/srv *(rw,sync,root_squash,subtree_check)

Setup /etc/fstab on local machine to mount remote directory:
192.168.10.0:/srv /srv/gateway-5648 nfs rw,hard,intr,noexec 0 0

Result:
After running exportfs -ar and restarting portmap, nfs-common, nfs-kernel-server, and networking services on the remote machine, and mounting the drive on the local machine I have the following results:

• running ls in the mounted directory shows the three subdirectories, 1,2 and 3 and any files located in teh that directory
• running ls in any of the subdirectories 1, 2, or 3 shows empty directories, even though there are files in those directories
• if I put a directory with files inside it into /srv on the remote machine, I can view them from the remote machine correctly

My Conclusion:
/etc/exports on the remote machine and /etc/fstab on the local machine are functioning correctly. There must me an issue with how the partitions are mounted in the /etc/fstab file on the remote machine.

What pertinent portions of etc/fstab looks like on the remote machine:

# /dev/sda7
UUID=24d6de4f-ed3e-45e6-8452-0182ecf86750 /srv/1 ext3 defaults 0 2
#
# /dev/sdb1
UUID=155cd725-06fc-4574-928b-f074fc1cae18 /srv/2 ext3 defaults 0 2
#
* /dev/sdb2
UUID=03974fe7-cdb8-4d02-a360-53b4419ff4aa /srv/3 ext3 defaults 0 2


Do you see something that would cause the problem I am experiencing?
Is there something somewhere else that I should be looking at??

Thanks again!!

At this point I am lost

[Little Girl]

Re: NFS Woes

Your /etc/fstab on the remote machine doesn't look like it has anything wrong with it, and since you're able to open the three folders, it's working. Let's see what your files are saying:

Your current /etc/exports file on the remote machine (gateway):

/srv *(rw,sync,root_squash,subtree_check)

This says I want to share my /srv folder with everybody. Have you tried to change the * to the IP of the laptop?

Your current /etc/fstab entry on the local machine (laptop):

192.168.10.0:/srv /srv/gateway-5648 nfs rw,hard,intr,noexec 0 0

This says the machine at 192.168.10.0 wants to share its /srv folder with me and I have to open the /srv/gateway-5648 folder on my laptop to see the share. Is that what you want it to say, or is there any part of it that's not quite right?

Not to worry - we can figure this out. We had a heck of a time with NFS when we first started using it, and it ended up that we had made a small oversight without even realizing it. Once we tracked it down, the whole thing ran like clockwork (and still does).

[kalberga]

Re: NFS Woes

Little Girl:

192.168.10.0 was a typo (not sure how that happened - it was actually 192.168.10.200, the IP of the remote machine). I went back in and changed the wild card in the remote exports file to point just to the laptop (I had intended to ratchet that back once I got nfs working for security reasons anyway). Long story short the system is still functioning the same.

I cant get past the fact that if I create a directory and files in /srv on the remote system its files are viewable over the network. As soon as I browse over into one of those other partitions things go blank. I keep coming back to that. Do you know if there is an issue with primary vs. extended partitions with NFS? I can't remember how I partitioned that drive...

... still pulling my hair out....

[Little Girl]

Re: NFS Woes

I don't know of any issue with primary vs. extended partitions. As far as I know, a partition is a partition is a partition, and they're all welcome.

You had said in an earlier post that you set the permissions to chmod 777 on the three directories in question, so you should have permission to access them. I'm baffled as to what's standing in your way.

If you're willing to do an experiment, try to start over with the two machines using test directories on both:
1. Create a directory on the remote machine named source.
2. Create three subdirectories under the source directory named 1, 2, and 3.
3. Put some files in the 1, 2, and 3 directories, but not in the source directory.
4. Create a directory on the local machine named clickme.
5. Add these to the /etc/fstab and /etc/exports files.
6. Refresh NFS.

Can you see the source and 1, 2, and 3 directories when you open the clickme directory on the local machine? Can you see the contents of each of them? If so, then maybe there will be a difference you can spot between those and the actual directories you want to share. Or... a slightly awkward work-around... you could create a soft or hard link to the actual directories in the dummy directories.

Last, but not least, go over each step you took when creating the share and make sure there are no typos anywhere, keeping in mind that case is important.

Meanwhile I'll check to see if I can find any information on special handling of certain types of partitions with NFS. Chin up - we'll figure this out. And the more we write in here, the more likely it is that someone else will stumble across it and figure it out in an instant.

[Little Girl]

Re: NFS Woes

I did some looking around and couldn't find any mention of specific partition types being off limits. My son and I did an experiment with him putting a link to his CD ROM on his Desktop. I have NFS access to his Desktop, but I wasn't even able to see the link to the CD ROM, let alone access it. The reason for that may be similar to why your shares aren't fully accessible. We've come to the conclusion that there are three possible ways for you to set this up, but we're not sure which of them will do the trick:

_________________________________________________

METHOD 1

The first way to try to set it up would be to edit the /etc/exports file on the remote machine and make sure it contains all of these entries (replace the * with the IP of the laptop in each line):

/srv *(rw,sync,root_squash,subtree_check)
/srv/1 *(rw,sync,root_squash,subtree_check)
/srv/2 *(rw,sync,root_squash,subtree_check)
/srv/3 *(rw,sync,root_squash,subtree_check)

Don't change the /etc/fstab on your laptop. We're hoping that since you're able to see the subdirectories with the way the file is currently set up, the addition of the three other exports will make it so you can access those directories properly. But we think this is probably unlikely, so if it works, we'll be pleased and rather surprised.
_________________________________________________

METHOD 2

If Method 1 doesn't work, and you don't need to read or write to the /srv directory itself, but just need access to /srv/1, /srv2, and /srv/3, then you can manually create these three directories on your laptop:

• /srv/gateway-5648/1
• /srv/gateway-5648/2
• /srv/gateway-5648/3

You would then edit the /etc/exports file on the remote machine and make sure it contains all of these entries (replace the * with the IP of the laptop in each line):

/srv/1 *(rw,sync,root_squash,subtree_check)
/srv/2 *(rw,sync,root_squash,subtree_check)
/srv/3 *(rw,sync,root_squash,subtree_check)

Then edit the /etc/fstab file on the laptop and make sure it has these entries:

192.168.10.200:/srv/1 /srv/gateway-5648/1 nfs rw,hard,intr,noexec 0 0
192.168.10.200:/srv/2 /srv/gateway-5648/2 nfs rw,hard,intr,noexec 0 0
192.168.10.200:/srv/3 /srv/gateway-5648/3 nfs rw,hard,intr,noexec 0 0

With this setup, you'll have access to the three subdirectories of /srv, but not to the /srv directory itself.
_________________________________________________

METHOD 3

This is the messiest of all of these solutions.

If Method 1 doesn't work and you do need access to the /srv directory on the gateway in addition to /srv/1, /srv2, and /srv/3, then you can manually create these four directories on your laptop:

• /srv/gateway-5648/srv
• /srv/gateway-5648/1
• /srv/gateway-5648/2
• /srv/gateway-5648/3

You would then edit the /etc/exports file on the remote machine and make sure it contains all of these entries (replace the * with the IP of the laptop in each line):

/srv *(rw,sync,root_squash,subtree_check)
/srv/1 *(rw,sync,root_squash,subtree_check)
/srv/2 *(rw,sync,root_squash,subtree_check)
/srv/3 *(rw,sync,root_squash,subtree_check)

Then edit the /etc/fstab file on the laptop and make sure it has these entries:

192.168.10.200:/srv /srv/gateway-5648/srv nfs rw,hard,intr,noexec 0 0
192.168.10.200:/srv/1 /srv/gateway-5648/1 nfs rw,hard,intr,noexec 0 0
192.168.10.200:/srv/2 /srv/gateway-5648/2 nfs rw,hard,intr,noexec 0 0
192.168.10.200:/srv/3 /srv/gateway-5648/3 nfs rw,hard,intr,noexec 0 0

With this setup, you'll be able to access all the shares, but each of them (including the /srv directory) will be in a subdirectory of its own.
_________________________________________________

Note that you may have to change all instances of root_squash in the above examples to no_root_squash if the /srv directory is owned by root.

Please don't become discouraged from all of this. Even though it's a bit messy, it looks worse than it is. You just seem to have an interesting situation for some reason.

[flarson]

Re: NFS Woes

Try

man exports

and look at the nohide and crossmnt options. The behavior you are seeing is standard NFS behavior and those options allow you to change it.

Since root_squash is the default it is not really needed. no_root_squash says that root on the client machine is granted root privileges on the server filesystem. If the filesystem is owned by root but has permissions that allow others to read/write or execute on the server, others on the client machine will have those permissions also, but root on the client will not have root power over the filesystem unless it is exported with no_root_squash.

[kalberga]

Re: NFS Woes

mando_hacker and Little Girl:

Thanks soo much for your help. I added crossmnt and nohide to the export file and that appears to have solved the problem. Amazing how the answer always seems to end up being right in front of you once it's been pointed out.

Thanks again for all your help and patience!!

--Kris