Hi, I would like to set up my to PC's to be able to access files from one another. One PC is running Debian (sid), the other is running 64studio. They are both connect to a 4 port router. I would like 2 way access, eg, PC1 can access PC2, and PC2 can access PC1. I have followed several NFS Howto's on the subject, they all tell you to set up 1 PC as a server, and one as a client. I have set things up as described, and was able to access the server from the client, but not the client from the server. So, do I need to set each PC up as both server and client to acheive what I want? installing nfs-kernel-server on both?

I realize that my not being able to connect from the server to the client may be caused by a myriad of other things, but just thought that it may be reasonable to assume that both would need to be servers as well as clients to allow 2 way access. I have fresh installs of both OS's, and would like some confirmation/help, before I make another attempt.

I am by no means a Linux expert, but am not a complete beginner (although closer to beginner than to expert), I have used Mandriva on and off over the last 2 years, and tried several flavours of 'buntu, Suse, PCLinuxOS, Fedora, etc, but have settled with Debian, and 64studio (Debian based), I know only what I need to know to do what I have to, so please keep that in mind.

Thanks for your help.

just a suggestion,

since you already setup the other pc as an nfs server, what if you will create a folder on that PC and make that one folder a repositories of files you want to access on both pc... assuming that you have setup an nfs rw share. On your nfs server, you can access that locally, and from your other end, you can access read and write on that remotely, mounting that just like a local folder, then thats it, you have a folder being access on both machine.. you don't need to create share on both, unless on some circumstances..

Hi, thanks, yes that has been thought of, but I would much prefer to be able to access at will from one PC to another, then I don't have to worry about having files in a certain directory, juggling them around, if I wanted to access a file on the client machine, from the server, I would have to physically go to the client, put the file in the 'repository' then go back to the server and access, much easier just to be able to have access to everything no mater which PC I am at.

I don't really know how it functions properly in Linux, it is something that until lately, I have never bothered to try, because I didn't really understand it, and the howto's and guides I read made it seem overly complicated. It was so easy under Windows. But this is not Windows.

Oh, and at present I haven't got anything set up for this, I have 2 relatively fresh OS installs, and was waiting for advice before attempting again. I like to keep things as clean as possible, and hate having stuff installed that I don't use or doesn't work, I'm a bit obsessive compulsive like that.

Thanks

hmmn... well, you can configure both the other way around, nfs (server-client / client-server).

Another way to access / manage both pc, enable ssh daemon on them, that way, you can remote access on each side.. just enable it

if not mistaken, it's already enabled by default.

then you can access your other pc via konqueror, open it up then at the url, type:

and it will ask you a username and password, those are the user/passwd of the remote machine.

that's another way of accessing/sharing your pc

Wouldn't it be a lot less messy setting both machines as a client and server? That way you have access to what ever you want to share on either pc. I forget how debian handles this, but it seems logical to me.

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.

What you are trying to do can be done with mandriva, I do this very same thing myself with three pc's. The only thing to watch out for is that you are not trying to share the same directory back to the server. I tried that by mistake. Other than that no problem. As I said I'm not familiar with how debian does this so I can't comment any further on that one.

And It would be better if you mount nfs shared folder with automount or autofs, that way, you dont have to make a permanent mount which sometimes can cause the other host to freeze when the nfs-server being accessed is not accessible. I mean with autofs, you can set a time-out so it will released the network mounted drive when being idle for certain period (set) and will re-mount it on demand. Please forgive me, it should be another topic, but sort of related to what you want...

just a suggestion though....

Thank you all, I just thought I would try and make sure I was heading in the direction, doing things correctly before I attempted it again, with your reassurances, and those I got from Debian folk, I feel confidant to proceed. [plus now I have more people to blame when I mess things up j/k]



No, no, I am glad you mentioned it, something else to look into, and if it helps to avoid problems, all the better, Thank you.

I'll go now and try, I'm sure I'll be back with more questions, when PC2 fails to be able to access PC1. [Hows that for confidence]

Yes, Yes, I have success!!!

I'm pleased it all worked out for you. What did you do in the end?

Well, I just installed nfs-kernel-server package on both machines, they both already had nfs-common and portmap installed, and then just edited the 'exports', 'hosts', 'hosts.deny' and 'hosts.allow' files, adding the required info, restarted the nfs-kernel-server, and that was it.

I also edited the fstab file, so as it would mount the shares automatically, but descided to remove that before I shutdown last night, in favour of mounting them manually, just incase I ran into any such problems as aioshin mentioned above when I booted up today. Still have to look into 'automount or autofs' and what he mentioned in his post.

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]

Hi all, ok, after getting everything working fine yesterday, today when I boot up my 2 PC's, PC2 has access to the share on PC1, but PC1 cannot access the share on PC2. Last night before I shut down everything, all was working fine. [Though I thought that when I booted up today that this would be the case, and I think the problem may be something to do with below]

When I go to mount the share, this is what I get, the ****** are of course added be me here,

mount.nfs: 64studio:/home/****** failed, reason given by server: Permission denied

PC2 has a file in the /etc/media directory called .hal-mtab-lock plus on PC1 the file /etc/mtab does not have an entry for PC2, such as,

64studio:/home/****** /media/****** nfs rw,addr=192.168.1.102 0 0

but /etc/mtab on PC2, has an entry for PC1,

debian:/home/****** /media/****** nfs rw,addr=192.168.1.101 0 0

Now if I delete the .hal-mtab-lock file on PC2, and do a /etc/init.d/nfs-kernel-server restart all will be fine, and everything will work as expected, and /etc/mtab on PC1 gets updated with the entry for PC2,

64studio:/home/****** /media/****** nfs rw,addr=192.168.1.102 0 0

But of course, on next boot, the file /etc/media/.hal-mtab-lock will be back on PC2, and the entry for PC1 in PC2's /etc/mtab will be not there, and I will again get the mount.nfs: 64studio:/home/****** failed, reason given by server: Permission denied error.

So, is my assumptions as to the problem correct? and if so how do I fix it?

Thanks

What I see is as follows:-
When you close down PC1 before PC2, PC2 does not have indication that PC1 has shutdown and therefore still has an entry (lock) in /etc/mtab and is not unmounted. When you come to reboot PC2, it tries to remount an already mounted network file system. Hence the permission denied.
If you did the opposite and shutdown PC2 first I think you would find the opposite happening.
This is difficult to explain and I don't know how you would get round it. I have to 'unmount' and then 'mount' whichever PC I shutdown last. Otherwise I cannot access whichever PC I shutdown first.
Cor my head is shutting down with this one.

Have you checked your /etc/hosts, /etc/hosts/allow and /etc/hosts/deny configuration files?

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.




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.

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

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.

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.

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


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

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 ?

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.

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 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.

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?

Thanks SileverSurfer60, I will look into that ASAP.



I would like to solve it , 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



No



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

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.

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.

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 :-

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.

I will give that a shot tonight, Thanks

Well I gave it a whirl



Negative Captain

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






Negative captain

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




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.

Ah well I tried. Sorry It didn't work out for you. If you weren't surprised I was.
I'm out of ideas now for Debian anyway. Looks like you will have to restart your server until someone comes up with something.
I'll carry on

Thank you for trying, I'm quite happy with having to do the nfs-kernel-restart dance, it's not much of an inconvenience, hell, I used put up with Windows for 7 years or so, this is heaven in comparison.

Linux Whatever flavour