Sponsored Content
Operating Systems Linux Red Hat Not able to mount NFS share on client side Post 302597275 by Shirishlnx on Thursday 9th of February 2012 09:53:44 PM
Old 02-09-2012
Pls try the below entry in /etc/export

/remote/proj1 *(rw, sync)

Hope help !!

In mean time pls check your /etc/hosts.allow and /etc/hosts.deny entries .. also ..ur service status portmap/nfs ...


--Shirish
 

10 More Discussions You Might Find Interesting

1. AIX

Unable to mount NFS share during boot

Hello Everyone, I have a pseries machine running AIX 4.3.3 that has an invalid IP in /etc/hosts. During a boot the system hangs because it's trying to mount an NFS share to this invalid IP. I've tried to boot the system from a mksysb (not sure if the device was defined as rmt0) and AIX CD... (0 Replies)
Discussion started by: jlslhills
0 Replies

2. UNIX for Advanced & Expert Users

can i mount nfs share on windows 2003 server

this is probably a bit dumb ...but i read somewhere that one of the nfs versions can be mounted on a windows 2003 server ..if yes ..does anyone know how this can be achieved (1 Reply)
Discussion started by: tarunicon
1 Replies

3. Solaris

how to mount Windows NFS share on solaris

Hi, How can i mount an NFS share on a solaris machine a filesystem ? I have enabled nfs on a windows server and the shares has given read/write access to it to all the users. I would like to mount it on around 10 different solaris boxes with different versions of solaris. Thanks in advance. (2 Replies)
Discussion started by: uxadmin007
2 Replies

4. IP Networking

Can't see home folder on one NFS mount but can in another mount on another share

Hello, I have a few Ubuntu 9.10 laptops I'm trying to learn NFS sharing with. I am just experimenting on this right now, so no harsh words about the security of what I'm playing with, please ;) Below are the configs /etc/exports on host /home/woodnt/Homeschool... (2 Replies)
Discussion started by: Narnie
2 Replies

5. Web Development

NFS Share & Mount problem

Hi, I want to mount an NFS Shared folder on Windows XP to vxWorks. There doesnt seem to be a problem with the sharing. Now, when i try to mount the directory onto vxWorks (it runs on a Tumbleweed card), using a mount script (.sh), the following is the print i see on Tera Term: hostAdd... (0 Replies)
Discussion started by: chinmayzen
0 Replies

6. UNIX for Advanced & Expert Users

NFS client-side userid mapping

Folks, I am trying to solve the following problem. I have a process on machine A running as root that needs to mount and access an NFS partition being exported from machine B. However, I cannot have 'no_root_squash' option given on B, hence I see NFS requests from machine A end up as 'nobody'... (1 Reply)
Discussion started by: helpmelearn
1 Replies

7. Solaris

Can't access NFS Share on Solaris Server from a Linux Client

Hi, I am trying to access a NFS shared directory on Solaris 10 Server from a client which is RHEL 4 Server. On the NFS Server, in /etc/dfs/, I added following line to dfstab file. & then ran the following On the client machine, while running the mount command, I am... (0 Replies)
Discussion started by: SunilB2011
0 Replies

8. SCO

Cannot mount NFS share (FreeNAS) onto SCO OpenServer 5.0.6

Hi! All, I am trying to mount a NFS share on my FreeNAS system onto my SCO OpenServer 5.0.6. I get the following error: mount: cannot mount /: Connection Refused (error 115) Has anyone been able to do this? (3 Replies)
Discussion started by: trolley
3 Replies

9. Shell Programming and Scripting

Mount NFS Share On NFS Client via bash script.

I need a help of good people with effective bash script to mount nfs shared, By the way I did the searches, since i haven't found that someone wrote a script like this in the past, I'm sure it will serve more people. The scenario as follow: An NFS Client with Daily CRON , running bash script... (4 Replies)
Discussion started by: Brian.t
4 Replies

10. Solaris

Solaris 10 NFS client cannot mount a share from a Windows server

I have a Solaris 10 server, I'm trying to mount a share from a Windows nfs server. If I add this entry (tst-walnut:/test_sap_nfs - /majid nfs - yes rw,soft) to my /etc/vfstab, then I can mount, but when I create a file by root:root, the file owner changes to... (1 Reply)
Discussion started by: Hiroshi
1 Replies
hosts.equiv(4)							   File Formats 						    hosts.equiv(4)

NAME
hosts.equiv, rhosts - trusted remote hosts and users DESCRIPTION
The /etc/hosts.equiv and .rhosts files provide the "remote authentication" database for rlogin(1), rsh(1), rcp(1), and rcmd(3SOCKET). The files specify remote hosts and users that are considered "trusted". Trusted users are allowed to access the local system without supply- ing a password. The library routine ruserok() (see rcmd(3SOCKET)) performs the authentication procedure for programs by using the /etc/hosts.equiv and .rhosts files. The /etc/hosts.equiv file applies to the entire system, while individual users can maintain their own .rhosts files in their home directories. These files bypass the standard password-based user authentication mechanism. To maintain system security, care must be taken in creating and maintaining these files. The remote authentication procedure determines whether a user from a remote host should be allowed to access the local system with the identity of a local user. This procedure first checks the /etc/hosts.equiv file and then checks the .rhosts file in the home directory of the local user who is requesting access. Entries in these files can be of two forms. Positive entries allow access, while negative entries deny access. The authentication succeeds when a matching positive entry is found. The procedure fails when the first matching nega- tive entry is found, or if no matching entries are found in either file. The order of entries is important. If the files contain both posi- tive and negative entries, the entry that appears first will prevail. The rsh(1) and rcp(1) programs fail if the remote authentication pro- cedure fails. The rlogin program falls back to the standard password-based login procedure if the remote authentication fails. Both files are formatted as a list of one-line entries. Each entry has the form: hostname [username] Hostnames must be the official name of the host, not one of its nicknames. Negative entries are differentiated from positive entries by a `-' character preceding either the hostname or username field. Positive Entries If the form: hostname is used, then users from the named host are trusted. That is, they may access the system with the same user name as they have on the remote system. This form may be used in both the /etc/hosts.equiv and .rhosts files. If the line is in the form: hostname username then the named user from the named host can access the system. This form may be used in individual .rhosts files to allow remote users to access the system as a different local user. If this form is used in the /etc/hosts.equiv file, the named remote user will be allowed to access the system as any local user. netgroup(4) can be used in either the hostname or username fields to match a number of hosts or users in one entry. The form: +@netgroup allows access from all hosts in the named netgroup. When used in the username field, netgroups allow a group of remote users to access the system as a particular local user. The form: hostname +@netgroup allows all of the users in the named netgroup from the named host to access the system as the local user. The form: +@netgroup1 +@netgroup2 allows the users in netgroup2 from the hosts in netgroup1 to access the system as the local user. The special character `+' can be used in place of either hostname or username to match any host or user. For example, the entry + will allow a user from any remote host to access the system with the same username. The entry + username will allow the named user from any remote host to access the system. The entry hostname + will allow any user from the named host to access the system as the local user. Negative Entries Negative entries are preceded by a `-' sign. The form: -hostname will disallow all access from the named host. The form: -@netgroup means that access is explicitly disallowed from all hosts in the named netgroup. The form: hostname -username disallows access by the named user only from the named host, while the form: + -@netgroup will disallow access by all of the users in the named netgroup from all hosts. Search Sequence To help maintain system security, the /etc/hosts.equiv file is not checked when access is being attempted for super-user. If the user attempting access is not the super-user, /etc/hosts.equiv is searched for lines of the form described above. Checks are made for lines in this file in the following order: 1. + 2. +@netgroup 3. -@netgroup 4. -hostname 5. hostname The user is granted access if a positive match occurrs. Negative entries apply only to /etc/hosts.equiv and may be overridden by subse- quent .rhosts entries. If no positive match occurred, the .rhosts file is then searched if the user attempting access maintains such a file. This file is searched whether or not the user attempting access is the super-user. As a security feature, the .rhosts file must be owned by the user who is attempting access. Checks are made for lines in .rhosts in the following order: 1. + 2. +@netgroup 3. -@netgroup 4. -hostname 5. hostname FILES
/etc/hosts.equiv system trusted hosts and users ~/.rhosts user's trusted hosts and users SEE ALSO
rcp(1), rlogin(1), rsh(1), rcmd(3SOCKET), hosts(4), netgroup(4), passwd(4) WARNINGS
Positive entries in /etc/hosts.equiv that include a username field (either an individual named user, a netgroup, or `+' sign) should be used with extreme caution. Because /etc/hosts.equiv applies system-wide, these entries allow one, or a group of, remote users to access the system as any local user. This can be a security hole. For example, because of the search sequence, an /etc/hosts.equiv file consist- ing of the entries + -hostxxx will not deny access to "hostxxx". SunOS 5.10 23 Jun 1997 hosts.equiv(4)
All times are GMT -4. The time now is 10:41 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy