fbackup with NFS

[Brian Amstutz]

I've been doing fbackup across an NFS mount for quite some time without any problem - until this week.

I started receiving several of the following messages from fbackup:
fbackup(1513): statcall failed in dotdotnotparent
fbackup(1507): WARNING: could not chdir to

Any ideas as to what might have happened or changed that would cause this?

Thanks!

Brian

[Bill Hassell]

The message is fairly clear: the user accessing the NFS mount point does not have permission to cd to the specified directory. Keep in mind that root-access to NFS directories is a serious security risk. Thus, root on some other system never has root privileges over NFS--unless explcitly given in the /etc/exports file.

However, I would never use NFS with fbackup. NFS is not only very slow (especially for backups) but also unreliable, especially when the network is unprotected (ie, PC's connected to it). fbackup and frecover have remote magtape capability which is more reliable and much less network overhead. Check the man page for fbackup about the -f remote-tape capability.

[Thomas Schler_1]

In addition what Bill sayed, when you use the -f option of fbackup you have to have a proper entry in .rhosts of the proper home directory on the remote node, since a tape protocol program must be started on the remote node using an user id known by the remote node.

Be aware of security problems when using .rhosts: This file must be readable only by the file owner (no other flags for anybody else). It should always be empty if you don't need it. If you need it you should only allow remote execution for a distinct user coming from a distinct node.

[Shahul]

Hi


U have been doing backup for some time..Now suddenly it stoped..right. It should be some configuration problem. So please checkup the related files.

Please checkup /etc/exports and /.rhosts files in the remote system and if rqd restart the nfs server in the remote system by typing
#/sbin/init.d/nfs.server stop
#/sbin/init.d/nfs.server start

From ur local system, Please checkup whether U are able to go to the particular directory which U want to take backup or not.
If rqd please restart the nfs client here by typing

#/sbin/init.d/nfs.client stop
#/sbin/init.d/nfs.client start


Best of luck


Shahul

[W.C. Epperson]

We occasionally see working NFS mounts across our hpux servers "break" for unexplained reasons. Typical symptoms are permissions errors and or the appearance that the contents of the filesystem have disappeared. Our standard response is to "exportfs -a" from the serving system, then unmount/mount the NFS filesystem on the client if its still broken. This frequently corrects problems that are not due to an actual misconfiguration of some kind.

[Brian Amstutz]

I have the NFS server set so that it will only accept root access from the NFS client machine (both on an internal network). I haven't had to mess with .rhosts before - I used sam to setup both the server and client. I tried deleting and re-adding the NFS mounts on both the client and the server and restarted both the NFS client and server process - all with no luck.

fbackup (running on the NFS client) can access some of the directories on the NFS server but not all. It looks like (at least some of) the ones that it can't access have no permission to "others" (e.g. drwxr-x---) Shouldn't "root" still have access to these?

Can fbackup do multiple volumes on 1 tape? i.e. can I do use fbackup on what currently is the NFS client, not rewind the tape, and then do a remote backup from what is currently the NFS server to the tape on the (current) NFS client - so that both backups are on 1 tape. That's really what I'm trying to accomplish - I want both file systems backed up on the same tape.

Thanks!

[Shahul]

Hi

I hope U are a user with supervisor privilage. Can U send the content of ur /etc/exports file?

Shahul

[Bill Hassell]

NFS is a very shaky protocol fromn a security point of view and the LAST thing you want is for root on one machine to have root privileges on another. To so so requires careful thought. The man page for exports will tell you how to do this. ALll of this is unnecessary if you use .rhosts with the aforementioned permissions, ie chmod 600 .rhosts and ALWAYS enumerate both the remote system and the root user in .rhosts for security.

As far as backing up a remote NFS filesystem and the local filesystem, it is just another filesystem to the local computer, except you must tell fbackup to allow NFS filesystems to be backed up.

If you use the remote magtape capability, then you will need 2 tapes. It is not a good idea at all to try to append multiple backups on one tape and fbackup forbids this as it requires a complete table of contents at the beginning of the tape (like all commercial quality backup programs).

[Brian Amstutz]

I configured NFS with SAM and here's the /etc/exports that it generated (I've replaced the actual client name with NFSCLIENT):
/ -root=NFSCLIENT,access=NFSCLIENT
/stand -root=NFSCLIENT,access=NFSCLIENT
/opt -root=NFSCLIENT,access=NFSCLIENT
/usr -root=NFSCLIENT,access=NFSCLIENT
/var -root=NFSCLIENT,access=NFSCLIENT
/users -root=NFSCLIENT,access=NFSCLIENT

From my understanding, this says that only root on NFSCLIENT can access the NFS server (and yes I'm the only one with root access on both machines).

Bill, when you say that "ALL of this is unnecessary if you use .rhosts..." - do you mean that the /etc/exports file is unnecessary if I have a .rhosts file or do you mean something else?

Thanks again! Brian