Simple Home Network

[qandd]

Well, yes I did, not that I may know what I am looking for, but they are exactly the same as when it was first working correctly, and still exactly the same as they are now with everything working as it should, after removing the .hal-mtab-lock file, and doing a /etc/init.d/nfs-kernel-server restart, I mean they don't seem to change or anything.

 

Anyway, this is what they contain,

 

hosts

 

127.0.0.1 localhost

127.0.1.1 debian.gandm.com debian

192.168.1.102 64studio

 

# The following lines are desirable for IPv6 capable hosts

::1 ip6-localhost ip6-loopback

fe00::0 ip6-localnet

ff00::0 ip6-mcastprefix

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

ff02::3 ip6-allhosts

 

 

hosts.allow

 

# /etc/hosts.allow: list of hosts that are allowed to access the system.

# See the manual pages hosts_access(5), hosts_options(5)

# and /usr/doc/netbase/portmapper.txt.gz

#

# Example: ALL: LOCAL @some_netgroup

# ALL: .foobar.edu EXCEPT terminalserver.foobar.edu

#

# If you're going to protect the portmapper use the name "portmap" for the

# daemon name. Remember that you can only use the keyword "ALL" and IP

# addresses (NOT host or domain names) for the portmapper, as well as for

# rpc.mountd (the NFS mount daemon). See portmap(8), rpc.mountd(8) and

# /usr/share/doc/portmap/portmapper.txt.gz for further information.

#

 

portmap: 192.168.1.102

lockd: 192.168.1.102

rquotad: 192.168.1.102

mountd: 192.168.1.102

statd: 192.168.1.102

 

 

hosts.deny

 

# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.

# See the manual pages hosts_access(5), hosts_options(5)

# and /usr/doc/netbase/portmapper.txt.gz

#

# Example: ALL: some.host.name, .some.domain

# ALL EXCEPT in.fingerd: other.host.name, .other.domain

#

# If you're going to protect the portmapper use the name "portmap" for the

# daemon name. Remember that you can only use the keyword "ALL" and IP

# addresses (NOT host or domain names) for the portmapper. See portmap(8)

# and /usr/doc/portmap/portmapper.txt.gz for further information.

#

# The PARANOID wildcard matches any host whose name does not match its

# address.

 

# You may wish to enable this to ensure any programs that don't

# validate looked up hostnames still leave understandable logs. In past

# versions of Debian this has been the default.

# ALL: PARANOID

 

portmap:ALL

lockd:ALL

mountd:ALL

rquotad:ALL

statd:ALL

 

 

The other PC is exactly the same, except it references this PC, and the ip is different.

 

 

Cor my head is shutting down with this one. :P

 

lol, all the PC1's and PC2's were making me a bit dizzy when I was typing out the first post, I was hoping it was making sense, I couldn't think to explain it better.

Edited August 14, 2007 by qandd

[spinynorman]

All is not well today though, when I booted up, just as I thought, PC1 could not access PC2. I will however start a new thread for that, seeing how this has been marked solved. [Hope that's ok]

It's best if we keep the discussion in one place, so I've merged the two threads, and removed the [solved]. ;)

[SilverSurfer60]

For simplicities sake let's stay with PC1 as a server and PC2 as a client.

Maybe a careful look through your syslog on PC2 after closing down PC1 and look for errors relating to your nfs file shares before closing down PC2, and again after starting up PC2. Almost certainly there will be a record in the log file that should point you in the right direction. Assuming you do have system log files in Debian, it's a long time since a played with that OS I can't remember.

[qandd]

Well, what a difference a day makes, for whatever reason, I booted up today and everything is fine, I have access both ways. So it seems it has nothing to do with the .hal-mtab-lock file, which is back, and the entry in /etc/mtab on PC1 that was missing yesterday is there today. The only thing I did different today was, I let PC2 boot up first, plus last night before shutting them both down, I manually unmounted the shares first before shutting down.

 

I don't feel like shutting down/rebooting at present, so I will wait until tomorrow, and this time I will boot up as I usually do, PC1 first, and see what happens. I do recall reading somewhere when this happened to me on my first attempt, something about either something being loaded/started out of sequence (vague I know, but my memory isn't what it used to be, and I think the chances of me finding that article again are next to none) causing a similar problem to what I had, this is why I thought to change the booting order of the PC's just to see, although I think the article I read was more to do with a part of the NFS/mounting/networking stuff being loaded/started in the wrong sequence causing something similar .

 

Thanks for staying with it SilverSurfer60, [i wasn't sure if anyone would find where the thread got to after that Spiny fellow moved it ;)] and if it occurs again I will have a look through the syslog. I will have a look through it later also to see if there is anything from yesterday.

[SilverSurfer60]

The only thing I did different today was, I let PC2 boot up first, plus last night before shutting them both down, I manually unmounted the shares first before shutting down.

I was thinking along those lines in that your shutdown scripts may need a little tweak to ensure that the shares are unmounted,

 

Thanks for staying with it SilverSurfer60

You are quite welcome. It gives they old gray matter something to do.

[qandd]

Well Today I boot up, this time PC1 first then PC2, and as expected PC1 cannot access PC2's share.

 

So all I do is /etc/init.d/nfs-kernel-server restart on PC2, and then everything is fine. At next boot up tomorrow I will again change the order in which I boot the PC's, this time PC2 first then PC1. I think it is a safe bet that everything will work fine without the need to restart the nfs-kernel-server or anything else. But I will wait to see.

 

So if it is the case that everything works as it should, as long as I boot PC2 first, how do I go about correcting this, so as it doesn't matter which PC boots first ?

[qandd]

Well, there goes that idea, I boot up today, PC2 first, but alas, I can't access PC2's share from PC1. Never happens that PC2 can't access PC1's share though, it's always PC1 can't access PC2's share.

 

All it takes is a /etc/init.d/nfs-kernel-server restart on PC2 to correct the situation, so I guess I can live with that.

Edited August 17, 2007 by qandd

[SilverSurfer60]

Which now leads me to believe the execution order of start-up scripts is suspect, as you mentioned once before.

If Debian has the same sort of start-up as Mandriva you need to check /etc/rc3.d/ for a link to the execution of a script that starts your nfs-kernel-server, this same link should also be in /etc/rc5.d/

If you don't know what I'm talking about please post the contents of /etc/rc5.d using the command

ls -l

and likewise the contents of /etc/init.d/

If you do understand the contents of the /etc/rc[whatever number].d then changing the execution order of the link may rectify the problem. i.e. let's say in /etc/rc3.d you have a link named S2nfs-kernel-server then rename it to S99nfs-kernel-server

I hope all this makes sense to you. That is if you would like to solve it. ;)

[mindwave]

This is what I want to do, I want to know if that is how it is supposed to be done, as all the howto's I have read only say, 1 PC as server, and 1 PC as client, which suggests to me that you can only access the server from the client, not the client from the server, or something, it confuses me.

 

I have had each set up as both server and client, but still only managed to be able to access PC1 from PC2, and not the other way around. I know this could be caused be many things, but.

 

I guess I really just need to know what is the correct way to achieve what I am after, I want both PC's to be able to access each others files, not just one being able to access the other.

 

 

youre not trying to use the same account on both pc's are you?

 

and does the account your tryng to use have access to the folder that you want it tosee?

[qandd]

Thanks SileverSurfer60, I will look into that ASAP.

 

That is if you would like to solve it. ;)

 

I would like to solve it :D, however if it wasn't to be, I could live with just having to issue the nfs-kernel-server restart command on PC2, it won't kill me :P

 

youre not trying to use the same account on both pc's are you?

 

No

 

and does the account your tryng to use have access to the folder that you want it tosee?

 

Yes, It does work fine, just that when I boot up, PC1 can almost never access the share on PC2 as is. But all I have to do is restart the nfs-kernel-server on PC2 by issuing /etc/init.d/nfs-kernel-server restart command on PC2 and then everything is perfect.

 

I got lots on today, may get a chance to look at your suggestion this afternoon SilverSurfer60, will let you know how it turns out. I was going to do it last night, but I was trying out the latest Sidux release, Sidux 2007 - 03, and got carried away, it can run as a live cd, very nice, must be the fastest, most responsive live CD I have ever tried, would love to see it installed to hard drive. Only thing for was that it was KDE, I've developed a real liking for Gnome.

 

Anyway, will let you know how it turns out.

 

Thanks

Edited August 17, 2007 by qandd

[qandd]

SilverSurfer60, well I tried changing the S20nfs-kernel-server files in both etc/rc3.d/ and etc/rc5.d/. both up and down and round and round ;), then rebooting, but there was no change, it still required the nfs-server-restart command to be run on PC2 before PC1 could mount the share.

[SilverSurfer60]

I understand what is not happening now (I think), it needs some more trouble shooting so I'll post back when I have something for you to try, unless someone else solves it for you in the mean time. :P

[SilverSurfer60]

As I was unable to re-create your fault 'cause I'm on a different distribution I changed tack and took the suggestion from Aoishin and setup autofs. It took a bit of working out because most of the howto's dealt with local shares. However I got it working fine in the end. It has solved a small problem for me, so it probably would be the route for you to go.

It is quite simple to set up and not much in the way of padding. To start with you will need to install autofs unless it's installed by default, mine wasn't. After installation you will have a new sub-directory in /etc called 'autofs' in this directory besides a couple of files you don't need to touch are two which you will need to edit. The first one is named 'auto.master' there is a bunch of lines in there commented out, leave them and make sure you have one pointed to the second file named 'auto.misc' this is the business file. In this file is an example, ignore it, and comment it out. Now you will list the directories on your network that you want to access :-

docs	-hosts   pc1:/home/qandd/docs

One line for each share. The first column designates the mount point. In the example above the mount point will be '/misc/docs'

The second column tells autofs you are using the network and third column is where the share is on the server.

That's it. All the permissions etc. are just the same on the server as they are for the nfs mount.

Now a couple of points are things you can tailor for yourself, one is in the file auto.conf and it is the timeout= Change this to a reasonable length of time for you. It is in seconds and tells the system how long to wait before disconnecting from the server. You can connect again anytime you need to access the directory.

The next thing you can tailor is the name of the file 'auto.misc' you can change the extender to what you want, something not in the directory tree preferable. This extender forms the root for your directory. Of course you will need to alter auto.master to point to your file otherwise it will not be read. If you feel like having a stab at it do so. I think you will be surprised. I was.

Edited August 19, 2007 by SilverSurfer60

[qandd]

I will give that a shot tonight, Thanks

[qandd]

Well I gave it a whirl :unsure:

 

After installation you will have a new sub-directory in /etc called 'autofs

 

Negative Captain

 

After installation, these are the only things on my machine relating to autofs

 

/lib/modules/2.6.21-2-686/kernel/fs/autofs
/lib/modules/2.6.21-2-686/kernel/fs/autofs/autofs.ko
/lib/modules/2.6.21-2-686/kernel/fs/autofs4
/lib/modules/2.6.21-2-686/kernel/fs/autofs4/autofs4.ko
/lib/modules/2.6.22-1-686/kernel/fs/autofs
/lib/modules/2.6.22-1-686/kernel/fs/autofs/autofs.ko
/lib/modules/2.6.22-1-686/kernel/fs/autofs4
/lib/modules/2.6.22-1-686/kernel/fs/autofs4/autofs4.ko
/usr/src/linux-headers-2.6.21-2-686/include/config/autofs
/usr/src/linux-headers-2.6.21-2-686/include/config/autofs4
/usr/src/linux-headers-2.6.21-2/fs/autofs
/usr/src/linux-headers-2.6.21-2/fs/autofs4
/usr/src/linux-headers-2.6.22-1-686/include/config/autofs
/usr/src/linux-headers-2.6.22-1-686/include/config/autofs4
/usr/src/linux-headers-2.6.22-1/fs/autofs
/usr/src/linux-headers-2.6.22-1/fs/autofs4

 

 

in this directory besides a couple of files you don't need to touch are two which you will need to edit. The first one is named 'auto.master' . . . second file named 'auto.misc' this is the business file.

 

Negative captain

 

There are no files anywhere on my machine called either 'auto.master' or 'auto.misc'

 

 

I think you will be surprised.

 

Negative Captain

 

 

 

 

 

I've looked through log files for anything I thought may be something, but nothing really that stands out to me. The last line of the syslog file says

 

Aug 22 19:16:01 64studio mountd[5128]: authenticated mount request from debian:665 for /home/*** (/home/***)

 

Which sounds like a good thing to me, (but I wouldn't know), but still nada, until I restart the nfs-kernel-server on PC2.

Edited August 22, 2007 by qandd