Nfs error - 1

nfs error - 1

This could be one of two problems. If it is a write permission problem, check the export options on the server by looking at /proc/fs/nfs/exports and make sure. Cause. This error usually indicates that the NFS server is unable to resolve the ip address of the NFS client to a hostname. You can do one of two things to fix this: On the NFS server, add the insecure option to the share in /etc/exports and re-run exportfs -.

Are: Nfs error - 1

Nfs error - 1
Nfs error - 1
GLOBAX ERROR RECVFROM UDP PORT
Next

NFS/Troubleshooting

Related articles

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Not all sections are up-to-date with NFSv4 changes. (Discuss in Talk:NFS/Troubleshooting)

Dedicated article for common problems and solutions.

exportfs: /etc/exports:2: syntax error: bad option list

Make sure to delete all space from the option list in.

exportfs: requires fsid= for NFS export

As not all filesystems are stored on devices and not all filesystems have UUIDs (e.g. FUSE), it is sometimes necessary to explicitly tell NFS how to identify a filesystem. This is done with the option:

/etc/exports/srv/nfs client(rw,sync,crossmnt,fsid=0) /srv/nfs/music client(rw,sync,fsid=10)

Group/GID permissions issues

If NFS shares mount fine, and are fully accessible to the owner, but not to group members; check the number of groups that user belongs to. NFS has a limit of 16 on the number of groups a user can belong to. If you have users with more than this, nfs error - 1, you need to enable the start-up flag on the NFS server:

/etc/nfs.conf[mountd] manage-gids=y

"Permission denied" when trying to write files as root

  • If you need to mount shares as root, and have full r/w access from the client, add the no_root_squash option to the export in :
/var/cache/pacman/pkg 192.168.1.0/24(rw,no_subtree_check,no_root_squash)
  • You must also add no_root_squash to the first line in :
/ 192.168.1.0/24(rw,fsid=root,no_root_squash,no_subtree_check)

"RPC: Program not registered" when showmount -e command issued

Make sure that and are running on the server site, see systemd. If they are not, start and enable them.

Also make sure NFSv3 is enabled, nfs error - 1. showmount does not work with NFSv4-only servers.

UDP mounts not working

nfs-utils disabled serving NFS over UDP in version 2.2.1. Arch core updated to 2.3.1 on 21 Dec 2017 (skipping over 2.2.1.) If UDP stopped working then, add under in. Then restart.

Timeout with big directories

Since nfs-utils version 1.0.x, every subdirectory is checked for permissions. This can lead to timeout on directories with a "large" number of subdirectories, even a few hundreds.

To disable this behaviour, add the option to to the share directory.

mount.nfs4: No such device

Make sure the kernel module has been loaded.

mount.nfs4: Invalid argument

Enable and start and make sure the appropriate daemons (nfs-idmapd, rpc-gssd, etc) are running on the server.

mount.nfs4: Network is unreachable

Users making use of systemd-networkd or NetworkManager might notice NFS mounts are not mounted when booting.

Force the network to be completely configured by enabling or. This may slow down the boot-process because fewer services run nfs error - 1 parallel.

Tip: If the NFS server is only expecting IPV4 addresses, and prestashop fatal error uncaught exception smartycompilerexception are usingset in your network profile to make sure that nfs error - 1 IPV4 address is acquired before the is reached.

mount.nfs4: an incorrect mount option was specified

This can happen if using the option without and/or running. Starting and enabling those services should resolve the issue.

Unable to connect from OS X clients

When trying to connect from an OS X client, you will see that everything is ok in the server logs, but OS Nfs error - 1 will refuse to mount your NFS share. You can do one of two things to fix this:

  • On the NFS server, add the option to the share in and re-run .

. OR .

  • On the OS X client, add the option to the command line. You can also set as a default client mount option in :
/etc/nfs.confnfs.client.mount.options = resvport

Using the default client mount option should also affect mounting the share from Finder via "Connect to Server.".

Unreliable connection from OS X clients

OS X's NFS client is optimized for OS X Servers and might present some issues with Linux servers. If you are experiencing slow performance, frequent disconnects and problems with international characters edit the default mount options by adding the line to on your Mac client. More information about the mount options can be found in the OS X mount_nfs man page.

Intermittent client freezes when copying large files

If you copy large files from your client machine to the NFS server, the transfer speed is very fast, but after some seconds the speed drops and your client machine intermittently locks up completely for some time until the transfer is finished.

Try adding as a mount option on the client (e.g. in ) to fix this problem.

mount.nfs: Operation not permitted

NFSv4

If you use Kerberos (), make sure the client and server clocks are correct. Using ntpd or systemd-timesyncd essbase error code 1012704 recommended. Also, check that the canonical name for the server as resolved on the client (see Domain name resolution) matches the name in the server's NFS principal.

NFSv3 and earlier

nfs-utils versions 1.2.1-2 or higher use NFSv4 by default, resulting in NFSv3 shares failing on upgrade. The problem can be solved by using either mount option or on the command line:

# mount.nfs remote targetdirectory -o .,vers=3. # mount.nfs remote targetdirectory -o .,nfsvers=3.

or in :

remote targetdirectory nfs .,vers=3. 0 0 remote targetdirectory nfs .,nfsvers=3., nfs error - 1. 0 0

mount.nfs: Protocol not supported

This error occurs when you include the export root in the path of the NFS source. For example:

# mount SERVER:/srv/nfs4/media /mnt mount.nfs4: Protocol not supported

Use the relative path instead:

# mount SERVER:/media /mnt

Permissions issues

If you find that you cannot set the permissions on files properly, make sure the user/user group are both on the client and server, nfs error - 1.

If all your files are owned byand you are using NFSv4, on both the client and server, you should error e5 canon mp280 that the has been started.

On some systems detecting the domain from FQDN minus hostname does not seem to work reliably, nfs error - 1. If files are still showing as after the above changes, editensure that is set to. For example:

/etc/idmapd.conf[General] Domain = domain.ext [Mapping] Nobody-User = nobody Nobody-Group = nobody [Translation] Method = nsswitch

Problems with Vagrant and synced_folders

If you get an error about unuspported protocol, you need to enable NFS over UDP on your host (or make Vagrant use NFS over TCP.) See #UDP mounts not working.

If Vagrant scripts are unable to mount folders over NFS, installing the net-tools package may solve the issue.

Performance issues

This NFS Howto page has some useful information regarding performance. Here are some further tips:

Diagnose the problem

  • Htop should be your first port of call. The most obvious symptom will be a maxed-out CPU.
  • Press F2, and under "Display options", enable "Detailed CPU time", nfs error - 1. Press F1 for an explanation of the colours used in the CPU bars. In particular, is the CPU spending most of its time responding to IRQs, or in Wait-IO (wio)?

Close-to-open/flush-on-close

Symptoms: Your clients are writing many small files, nfs error - 1. The server CPU is not maxed out, but there is very high wait-IO, and the server disk seems to be churning more than you might expect.

In order to ensure data consistency across clients, the NFS protocol requires that the client's cache is flushed (all data is pushed to the server) whenever a file is closed after writing. Because the server is not allowed to buffer disk writes (if it crashes, nfs error - 1, the client will not realise the data was not written properly), the data is written to disk immediately before the client's request is completed. When you are writing lots of small files from the client, this means that the server spends most of its time waiting for small files to be written nfs error - 1 its disk, which can cause a significant reduction in throughput.

See this excellent article or the nfs manpage for more details on the close-to-open asus sata port 1 device error. There are several approaches to solving this problem:

The nocto mount option

Warning: The Linux kernel does not seem to honor this option properly. Files are still flushed when they are closed.

If all of the following conditions are satisfied:

  • The export you have mounted on the client is only going to be used by the one client.
  • It does not matter too much if a nfs error - 1 written on one client does not immediately appear on other clients.
  • It does not matter if after a client has written a file, and the client thinks the file has been saved, and then the client crashes, the file may be lost.

Use the nocto mount option, which will disable the close-to-open behavior.

The async export option

Does your situation match these conditions?

  • It is important that when a file is closed after writing on one client, it is:
    • Immediately visible on all the other clients.
    • Safely stored on the server, even if the client sacred 2 startup error ati immediately after closing the file.
  • It is not important to you that if the server crashes:
    • You may lose the files that were most recently written by clients.
    • When the server is restarted, nfs error - 1, the clients will believe their recent files exist, even though they were actually lost.

In this situation, nfs error - 1, you can use instead of in the server's file for those specific exports. See the exports manual page for details. In this case, it does not make sense to use the mount option on the client, nfs error - 1.

Buffer cache size and MTU

Symptoms: High kernel or IRQ CPU usage, a very high packet count through the network card.

This is a trickier optimisation. Make sure this is definitely the problem before spending too much time on this. The default values are usually fine for most situations.

See this article for information about I/O buffering in NFS. Essentially, data is accumulated into buffers before being sent. The size of the buffer will affect the way data is transmitted over the network. The Maximum Transmission Unit (MTU) of the network equipment will also affect throughput, as the buffers need to be split into MTU-sized chunks before they are sent over the network. If your buffer size is too big, the kernel or hardware may spend too much time splitting it into MTU-sized chunks. If the buffer size is too small, there will be overhead involved in sending a very large number of small packets, nfs error - 1. You can use the rsize and wsize mount options on the client to alter the buffer cache size. To achieve the best throughput, you need to experiment and discover the best values for your setup.

It is possible to change the MTU of many network cards. If your clients are on a separate subnet (e.g. for a Beowulf cluster), it may be safe to configure all of the network cards to use a high MTU, nfs error - 1. This should be done in very-high-bandwidth environments.

See NFS#Performance tuning for more information.

Debugging

Using rpcdebug

Using is the easiest way to manipulate the kernel interfaces in place of echoing bitmasks to /proc, nfs error - 1.

OptionDescription
-cClear the given debug flags
-sSet the given debug flags
-m moduleSpecify which module's flags to set or clear.
-vIncrease the verbosity of rpcdebug's output
-hPrint a help ragnarok gravity error 2011 and exit. When combined with nfs error - 1 -v option, also prints nfs error - 1 getsockoptso_error + error code 110 debug flags.

For the -m option, the available modules are:

ModuleDescription
nfsdThe NFS server
nfsThe NFS client
nlmThe Network Lock Manager, in either an NFS client or server
rpcThe Remote Procedure Call module, in either an NFS client or server

Examples:

rpcdebug retry ppp password on authentication error rpc -s all # sets all debug flags for RPC rpcdebug -m rpc -c all # clears all debug flags for RPC rpcdebug -m nfsd -s all # sets all debug flags for NFS Server rpcdebug -m nfsd -c all # clears all debug flags for NFS Server

Once the flags are set you can tail the journal for the debug output, usually by running as root or similar.

Using mountstats

The nfs-utils package contains the tool, which can retrieve a lot of statistics about NFS mounts, including average timings and packet size.

$ mountstats Stats for example:/tank mounted on /tank: NFS mount options: rw,sync,vers=4.2,rsize=524288,wsize=524288,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,soft,proto=tcp,port=0,timeo=15,retrans=2,sec=sys,clientaddr=xx.yy.zz.tt,local_lock=none NFS server capabilities: caps=0xfbffdf,wtmult=512,dtsize=32768,bsize=0,namlen=255 NFSv4 capability flags: bm0=0xfdffbfff,bm1=0x40f9be3e,bm2=0x803,acl=0x3,sessions,pnfs=notconfigured NFS security flavor: 1 pseudoflavor: 0 NFS byte counts: applications read 248542089 bytes via read(2) applications wrote 0 bytes via write(2) applications read 0 bytes via O_DIRECT read(2) applications wrote 0 bytes via O_DIRECT write(2) client read 171375125 bytes via NFS READ client wrote 0 bytes via NFS WRITE RPC statistics: 699 RPC requests sent, 699 RPC replies received (0 XIDs not found) average backlog queue length: 0 READ: 338 ops (48%) avg bytes sent per op: 216 avg bytes received per op: 507131 backlog wait: 0.005917 RTT: 548.736686 total execute time: 548.775148 (milliseconds) GETATTR: 115 ops (16%) avg bytes sent per op: 199 avg bytes received per op: 240 backlog wait: 0.008696 RTT: 15.756522 total execute time: 15.843478 (milliseconds) ACCESS: 93 ops (13%) avg bytes sent per op: 203 avg bytes received per op: 168 backlog wait: 0.010753 RTT: 2.967742 total execute time: 3.032258 (milliseconds) LOOKUP: 32 ops (4%) avg bytes sent per op: 220 avg bytes received per op: 274 backlog wait: 0.000000 RTT: 3.906250 total execute time: 3.968750 (milliseconds) OPEN_NOATTR: 25 ops (3%) avg bytes sent per op: 268 avg bytes received per op: 350 backlog wait: 0.000000 RTT: 2.320000 total execute time: 2.360000 (milliseconds) CLOSE: 24 ops (3%) avg bytes sent per op: 224 avg bytes received per op: 176 backlog wait: 0.000000 RTT: 30.250000 total execute nfs error - 1 30.291667 (milliseconds) DELEGRETURN: 23 ops (3%) avg bytes sent per op: 220 avg bytes received per op: 160 backlog wait: 0.000000 RTT: 6.782609 total execute time: 6.826087 (milliseconds) READDIR: 4 ops (0%) avg bytes sent per op: 224 avg bytes received per op: 14372 backlog wait: 0.000000 RTT: 198.000000 total execute time: 198.250000 (milliseconds) SERVER_CAPS: 2 ops (0%) avg bytes sent per op: 172 avg bytes received per op: 164 backlog wait: 0.000000 RTT: 1.500000 total execute time: 1.500000 (milliseconds) FSINFO: 1 ops (0%) avg bytes sent per op: 172 avg bytes received per op: 164 backlog wait: 0.000000 RTT: 2.000000 total execute time: 57 301-keyboard error (milliseconds) PATHCONF: 1 ops (0%) avg bytes sent per op: 164 avg bytes received per op: 116 backlog wait: 0.000000 RTT: 1.000000 total execute time: 1.000000 (milliseconds)

Kernel Interfaces

A bitmask of the debug flags can be echoed into the interface to enable output to syslog; 0 socket error 10053 in outlook the default:

/proc/sys/sunrpc/nfsd_debug /proc/sys/sunrpc/nfs_debug /proc/sys/sunrpc/nlm_debug /proc/sys/sunrpc/rpc_debug

Sysctl controls are registered for these interfaces, so they can be used instead of echo:

sysctl -w sunrpc.rpc_debug=1023 sysctl -w sunrpc.rpc_debug=0 sysctl -w sunrpc.nfsd_debug=1023 sysctl -w sunrpc.nfsd_debug=0

At runtime the server holds information that can be examined:

grep. /proc/net/rpc/*/content cat /proc/fs/nfs/exports cat /proc/net/rpc/nfsd ls -l /proc/fs/nfsd

A rundown of (the userspace tool pretty-prints this info):

* rc (reply cache): <hits> <misses> <nocache> - hits: client it's retransmitting - misses: a operation that requires caching - nocache: a operation that no requires caching * fh (filehandle): <stale> <total-lookups> <anonlookups> <dir-not-in-cache> <nodir-not-in-cache> - stale: file handle errors - total-lookups, anonlookups, dir-not-in-cache, nodir-not-in-cache . always seem to be zeros * io (input/output): <bytes-read> <bytes-written> - bytes-read: bytes read directly from disk - bytes-written: bytes written to disk * th (threads): <threads> <fullcnt> <10%-20%> <20%-30%> . <90%-100%> <100%> DEPRECATED: All fields after <threads> are hard-coded to - threads: number of nfsd threads - fullcnt: number of times that the last 10% of threads are busy - 10%-20%, 20%-30% . 90%-100%: 10 numbers representing 10-20%, 20-30% to 100% nfs error - 1. Counts the number of times a given interval are busy * ra (read-ahead): <cache-size> <10%> <20%> ., nfs error - 1. <100%> <not-found> - cache-size: always the double of number threads - 10%, 20% . 100%: how deep it found what was looking for - not-found: not found in the read-ahead cache * net: <netcnt> <netudpcnt> <nettcpcnt> <nettcpconn> - netcnt: counts every read - netudpcnt: counts every UDP packet it receives - nettcpcnt: counts every time it receives data from a TCP connection - nettcpconn: count every TCP connection it receives * rpc: <rpccnt> <rpcbadfmt+rpcbadauth+rpcbadclnt> <rpcbadfmt> <rpcbadauth> <rpcbadclnt> - rpccnt: counts all rpc operations - rpcbadfmt: counts if while processing a RPC it encounters the following errors: . err_bad_dir, err_bad_rpc, err_bad_prog, err_bad_vers, err_bad_proc, err_bad - rpcbadauth: bad authentication . does not count if you try to mount from a nfs error - 1 that it's not in your exports file - rpcbadclnt: unused * procN (N = vers): <vs_nproc> <null> <getattr> <setattr> <lookup> <access> <readlink> <read> <write> <create> <mkdir> <symlink> <mknod> <remove> <rmdir> <rename> <link> <readdir> <readdirplus> <fsstat> <fsinfo> <pathconf> <commit> - vs_nproc: number of procedures for NFS version . v2: nfsproc.c, 18 . v3: nfs3proc.c, 22 - v4, nfs4proc.c, 2 - statistics: generated from NFS operations at runtime * proc4ops: <ops> <x.y> - ops: the definition of LAST_NFS4_OP, OP_RELEASE_LOCKOWNER = 39, plus 1 (so 40); defined in nfs4.h - x.y: the array of nfs_opcount up to LAST_NFS4_OP (nfsdstats.nfs4_opcount[i])

NFSD debug flags

/usr/include/linux/nfsd/debug.h/* * knfsd debug flags */ #define NFSDDBG_SOCK 0x0001 #define NFSDDBG_FH 0x0002 #define NFSDDBG_EXPORT 0x0004 #define NFSDDBG_SVC 0x0008 #define NFSDDBG_PROC 0x0010 #define NFSDDBG_FILEOP 0x0020 #define NFSDDBG_AUTH 0x0040 #define NFSDDBG_REPCACHE 0x0080 #define NFSDDBG_XDR 0x0100 #define NFSDDBG_LOCKD 0x0200 #define NFSDDBG_ALL nfs error - 1 0x7FFF #define NFSDDBG_NOCHANGE 0xFFFF

NFS debug flags

/usr/include/linux/nfs_fs.h/* * NFS debug flags */ #define NFSDBG_VFS 0x0001 #define NFSDBG_DIRCACHE 0x0002 #define NFSDBG_LOOKUPCACHE 0x0004 #define NFSDBG_PAGECACHE 0x0008 #define NFSDBG_PROC 0x0010 #define NFSDBG_XDR 0x0020 #define NFSDBG_FILE 0x0040 #define NFSDBG_ROOT 0x0080 #define NFSDBG_CALLBACK 0x0100 #define NFSDBG_CLIENT 0x0200 #define NFSDBG_MOUNT 0x0400 #define NFSDBG_FSCACHE 0x0800 #define NFSDBG_PNFS 0x1000 #define NFSDBG_PNFS_LD 0x2000 #define NFSDBG_STATE 0x4000 #define NFSDBG_ALL 0xFFFF

NLM debug flags

/usr/include/linux/lockd/debug.h/* * Debug flags */ error 017 undefined symbol player name NLMDBG_SVC 0x0001 #define NLMDBG_CLIENT 0x0002 #define NLMDBG_CLNTLOCK 0x0004 #define NLMDBG_SVCLOCK 0x0008 #define NLMDBG_MONITOR 0x0010 #define NLMDBG_CLNTSUBS 0x0020 #define NLMDBG_SVCSUBS 0x0040 #define NLMDBG_HOSTCACHE 0x0080 #define NLMDBG_XDR 0x0100 #define NLMDBG_ALL 0x7fff

RPC debug flags

/usr/include/linux/sunrpc/debug.h/* * RPC debug facilities */ #define RPCDBG_XPRT 0x0001 #define RPCDBG_CALL 0x0002 #define RPCDBG_DEBUG 0x0004 #define RPCDBG_NFS 0x0008 #define RPCDBG_AUTH 0x0010 #define RPCDBG_BIND 0x0020 #define RPCDBG_SCHED 0x0040 #define RPCDBG_TRANS 0x0080 #define RPCDBG_SVCXPRT 0x0100 #define RPCDBG_SVCDSP 0x0200 #define RPCDBG_MISC 0x0400 #define RPCDBG_CACHE 0x0800 #define RPCDBG_ALL nfs error - 1 0x7fff

See also

NFS Error Messages


Solution:

You must include a file name with the option. You cannot use directory names.


Description:

This message is often created when the services information in the namespace has not been updated. The message can also be reported for UDP.

Solution:

To fix this problem, nfs error - 1, you must update the services data in the namespace.

For NIS+, the entries should be as follows:


nfsd nfsd tcp 2049 NFS server daemon nfsd nfsd udp 2049 NFS server daemon

For NIS andthe entries should be as follows:


nfsd 2049/tcp nfs # NFS server daemon nfsd 2049/udp nfs # NFS server daemon

Solution:

Include the option with the option essbase error 1012500 the share command. You must define the public file handle in order for the service call 980 fatal error oki c810 option to work.


Note –

The Solaris 2.5.1 release required that the public file handle be set by using the command. A change in the Solaris 2.6 release sets the public file handle to be () by default. This error message is no longer relevant.



Description:

This message is displayed if the daemon terminates abnormally seize domain naming master invalid syntax error if a system call error occurs. The string defines the problem.

Solution:

Contact Sun for assistance. This error message is rare and has no straightforward solution.


Description:

This message is displayed if the option is specified but the NFS server does not support the public file handle. In this situation, the mount fails.

Solution:

To remedy this situation, either try the mount request without using the public file handle or reconfigure the NFS server to support the public file handle.


Description:

The daemon is already running.

Solution:

If you want to run a new copy, kill the current version and start a new version.


Description:

This message is displayed when the that is associated with a daemon cannot be locked properly.

Solution: error distribution for floyd-steinberg algorithm Sun for assistance. This error message is rare and has no straightforward solution.


Description:

This message is displayed when the that is associated with a daemon cannot be opened properly.

Solution:

Contact Sun for assistance. This error message is rare and has no straightforward solution.


Description:

This message is displayed on the console when a failover occurs. The message is advisory only.

Solution:

No action required.


Description:

An NFS version 2 client is trying to access a file that is over 2 Gbytes.

Solution:

Avoid using NFS version 2. Mount the file system with version 3 runtime error 87 version 4. Also, nfs error - 1, see the description of the option in Options for NFS File Tls error unroutable control

The server that is sharing the file system you are trying to mount is down or unreachable, at the wrong run level, or its is error e 61 10 or hung.

Solution:

Wait for the server to reboot. If the server is hung, nfs error - 1, reboot nfs error - 1 server.


Description:

The mount request registered withbut the NFS mount daemon is not registered.

Solution:

Wait for the server to reboot. If the server is hung, reboot the server.


Description:

Either the remote directory or the local directory does not exist.

Solution:

Check the spelling of the directory names. Run on both directories.


Description:

Your computer name might not be in the list of clients or netgroup that is allowed access to the file system you tried to mount.

Solution:

Use to verify the access list.


Description:

An NFS version 4 server can delegate the management of a file to a client. This message indicates that the server is recalling a delegation for another client that conflicts with a request from your client.

Solution:

The recall must occur before the server can process your client's request. For more information about delegation, refer to Delegation in NFS Version 4.


Description:

This error can be caused by many situations. One of the most difficult situations to debug is when this problem occurs because a user is in too many groups. Currently, a user can be in no more than 16 groups if the user is accessing files through NFS mounts.

Solution:

An alternate does exist for nfs error - 1 who need to be in more than 16 groups. You can use access control lists to provide the needed access privileges if you run at minimum the Solaris 2.5 release on the NFS server and the NFS clients.


Description:

The flag is nfs error - 1 valid.

Solution:

Refer to the mount_nfs(1M) man page to verify the required syntax.


Note –

This error message is not displayed when nfs error - 1 any version of the command that is included in a Solaris release from 2.6 to the current release or in earlier versions that have been patched.



Description:

An NFS client has attempted to mount a file system from an NFS server by using the option.

Solution:

This option is not supported nfs error - 1 NFS file system types.


Description:

The NFS version 2 protocol cannot handle large files.

Solution:

You must use version 3 or version 4 if access to large files is required.


Description:

If programs hang while doing file-related work, your NFS server might have failed. This message indicates that NFS server is down or that a problem has occurred with the server or the network.

Solution:

If failover is being used, is a list of servers. Start troubleshooting with How to Check Connectivity on an NFS Client.


Description:

During part of the NFS version 4 server reboot, some operations were not permitted. This message indicates that the client is waiting for the server to permit this operation to proceed.

Solution:

No action required. Wait for the server to permit the operation.


Description:

This message is displayed by the, and commands for the following reasons:

  • If the user or group that exists in an access control list (ACL) entry on an NFS version 4 server cannot be mapped to a valid user or group on an NFS version 4 client, the user is not allowed to read the ACL on the client.

  • If the user or group that exists in an ACL entry that is being set on an NFS version 4 client cannot be mapped to a valid user or group on an NFS version 4 server, the user is not allowed to write or modify an ACL on the client.

  • If an NFS version 4 client and server have mismatched NFSMAPID_DOMAIN values, ID mapping fails.

For more information, nfs error - 1, see ACLs and in NFS Version 4.

Solution:

Do the following:

  • Make sure that all user and group IDs in the ACL entries exist on both the client and server.

  • Make sure that the value for NFSMAPID_DOMAIN is set correctly in the file. For more information, see Keywords for the File.

To determine if any user or group cannot be mapped on the server or client, use the script that is provided in Checking for Unmapped User or Group IDs.


Description:

The port number that is included in the NFS URL must match the port number that is included with the option to mount. If the port numbers do not match, the mount fails.

Solution:

Either change the command to make the port numbers identical or do not specify the port number that is incorrect. Usually, you do not need to specify the port number with both the NFS URL and the option.


Description:

For NFS failover to function properly, the NFS servers that are replicas must support the same version of the NFS protocol.

Solution:

Running multiple versions is not allowed.


Description:

NFS failover does not work on file systems that are mounted read-write. Mounting the file system read-write increases the likelihood that a file could change.

Solution:

NFS failover depends on the file systems being identical.


Description:

Replicated mounts require that you wait for a timeout before failover occurs.

Solution:

The option requires that the nfs error - 1 fail immediately when a timeout starts, so you cannot include the option with a replicated mount.


Solution:

Check that the file has only one file system selected to be shared with the option. Only one public file handle can be established per server, so only one file system per server can be shared with this option.


Description:

An NFS client has unsuccessfully attempted to establish a connection with the network lock manager on an NFS server. Rather than fail the mount, this warning is generated to warn you that locking does not work.

Solution:

Upgrade the server with a new version of the OS that provides complete lock manager support.

This is intended as a step-by-step guide to what to do when things go wrong using NFS. Usually trouble first rears its head on the client end, so this diagnostic will begin there.

7.1. Unable to See Files on a Mounted File System

First, check to see if the file system is actually mounted. There are several ways of doing this. The most reliable way is to look at the filewhich will list all mounted filesystems and give details about them, nfs error - 1. If this doesn't work (for example if you don't have the filesystem compiled into your kernel), you can type mount -f although you get less information.

If the file system appears to be mounted, then you may have mounted another file system on top of it (in error1606 autocad 2008 case you should unmount and remount both volumes), or you may have exported the file system on the server before you mounted it there, in which case NFS is exporting the underlying mount point (if so then you need to restart NFS on the server).

If the file system is not mounted, then attempt to mount it. If this does not work, see Symptom 3.

7.2. File requests hang or timeout waiting for access to the file

This usually means that the client is unable to communicate with the server. See Symptom 3 letter b.

7.3. Unable to mount a file system

There are two common errors that mount produces when it is unable to mount a volume, nfs error - 1. These are:

  1. failed, reason given by server: Permission denied

    This means that the server does not recognize that you have access to the volume.

    • Check your file and make sure that the volume is exported and that your client nfs error - 1 the right kind of access to it. For example, if a client only has read access then you have to mount the volume with the option rather than the option.
    • Make sure that you have told NFS to register any changes you made to since starting nfsd by running the exportfs command. Be sure to type exportfs -ra to be extra certain that the exports are being re-read.
    • Check the file and make sure the volume and client are listed correctly. (You can also look at the file for an unabridged list of how all the active export options are set.) If they are not, then you have not re-exported properly. If they are listed, make sure the server recognizes your client as being the machine you think it is. For example, you may have an old listing for the client in /etc/hosts that is throwing off the server, or you may not have listed the client's complete address and it may be resolving to a machine in a different domain. One trick is login to the server from the client via ssh or telnet; if you then type who, one of the listings should be your login session and the name of your client machine as the server sees it. Try using this machine name in your entry. Finally, try to ping the client from the server, and try to ping the server from the client. If this doesn't work, or if there is packet loss, you may have lower-level network problems.
    • It is not possible to export both a directory and its child (for example error bad argument type stringp nil autocad and ). You should export the parent directory with the necessary permissions, and all of its subdirectories can then be mounted with those same permissions.
  2. RPC: Program Not Registered (or another "RPC" error)

    This means that the client does not detect NFS running on the server. This could be for several reasons.

    • First, nfs error - 1, check that NFS actually is running on the server by typing rpcinfo -p on the server. You should see something like this: program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100011 1 udp 749 rquotad 100011 2 udp 749 rquotad 100005 1 udp 759 mountd 100005 1 tcp 761 mountd 100005 2 udp 764 mountd 100005 2 tcp 766 mountd 100005 3 udp 769 mountd 100005 3 tcp 771 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 300019 1 tcp 830 amd 300019 1 udp 831 amd 100024 1 udp 944 status 100024 1 tcp 946 status 100021 1 udp 1042 nlockmgr 100021 3 udp 1042 nlockmgr 100021 4 udp 1042 nlockmgr 100021 1 tcp 1629 nlockmgr 100021 3 tcp 1629 nlockmgr 100021 4 tcp 1629 nlockmgr This says that we have NFS versions 2 and 3, rpc.statd version 1, network lock manager (the service name for rpc.lockd) versions 1, 3, and 4. There are also different service listings depending on whether NFS is travelling over TCP or UDP. UDP is usually (but not always) the default unless TCP nfs error - 1 explicitly requested.

      If you do not see at least portmapper, nfs, and mountd, then you need to restart NFS. If you are not able to restart successfully, proceed to Symptom 9.

    • Now check to make sure you can see it from the client. On the client, type rpcinfo -p where server is the DNS name or IP address of your server.

      If you get a listing, then make sure that the type of mount you are trying to perform is supported. For example, if you are trying to mount using Version 3 NFS, make sure Version 3 is listed; if you are trying to mount using NFS over TCP, make sure that is registered. (Some non-Linux clients default to TCP). Type for more details on how to read the output. If the type of mount you are trying to perform is not listed, try a different type of mount.

      If you get the error No Remote Programs Registered, then you nfs error - 1 to check your and files on the server and make sure your client actually is allowed access, nfs error - 1. Again, if the entries appear correct, check (or conter terrorism bluetooch DNS server) and make sure that the machine is listed correctly, and make sure you can ping the server from the client. Also check the error logs on the system for helpful messages: Authentication errors from bad entries will usually appear inbut may appear somewhere else depending on how your system logs are set up, nfs error - 1. The man pages for syslog can help you figure out how your logs are set up. Finally, some older operating systems may behave badly when routes between the two machines are asymmetric. Try typing tracepath [server] from the client and see if the word "asymmetric" shows up anywhere in the output. If it does then this may be causing packet loss. However asymmetric routes are not usually a problem on recent linux distributions.

      If you get the error Remote system error - No route to host, but you can ping the server correctly, then you are the victim of an overzealous firewall. Check any firewalls that may be set up, either on the server or on any routers in between the client and the server. Look at the man pages for ipchains, netfilter, and ipfwadm, as well as the IPChains-HOWTO and the Firewall-HOWTO for help, nfs error - 1.

7.4. I do not have permission to access files on the mounted volume

This could be one of two problems. If it is a write permission problem, check the export options on the server by looking at and make sure the filesystem is not exported read-only. If it is you nfs error - 1 need to re-export it read/write nfs error - 1 forget to run exportfs -ra after editing ). Also, check and make sure the volume is mounted read/write (although if it is mounted read-only you ought to get a more specific error message). If not then you need to re-mount with the option, nfs error - 1.

The second problem has to do with username mappings, and is different depending on whether you are trying to do this as root or as a non-root user.

If you are not root, then usernames may not be in sync on the client and the server. Type id [user] on both the client and the server and make sure they give the same UID number. If they don't then you are having problems with NIS, NIS+, rsync, or whatever system you use to sync usernames. Check group names to make sure that they match as well. Also, make sure you are not exporting with the option. If the user names match then the user has a more general permissions problem unrelated to NFS.

If you are root, then you are probably not exporting with the option; check or on the server and make sure the option is listed. In general, being able to write to the NFS server as root is a bad idea unless you have an urgent fatal error lnk1104 radasm -- which is why Linux NFS prevents it by default. See Section 6, “Security and NFS” for details.

If you have root squashing, you want to keep it, and you're only trying to get root to have the same permissions on the file that the user nobody should have, then remember that it is the server that determines which uid root gets mapped to. By default, the server uses the UID and GID of nobody in the file, but this can also be overridden with the and options in the file. Make sure that the client and the server agree about which UID nobody gets mapped to, nfs error - 1.

7.5. When I transfer really big files, NFS takes over all the CPU cycles on the server and it screeches to a halt

This is a problem with the fsync() function in 2.2 kernels that causes all sync-to-disk requests to be cumulative, resulting in a write time that is quadratic in the file size. If you can, upgrading to a 2.4 kernel should solve the problem. Also, exporting with the option forces the program to use o_sync() instead, which may prove faster.

7.6. Strange error or log messages

  1. Messages of the following format: Jan 7 09:15:29 server kernel: fh_verify: mail/guest permission failure, acc=4, error=13 Jan 7 09:23:51 server kernel: fh_verify: ekonomi/test permission failure, acc=4, error=13

    These happen when a NFS setattr operation is attempted on a file you don't have write access to. The messages are harmless.

  2. The following messages frequently appear in the logs: kernel: nfs: server server.domain.name not responding, nfs error - 1, still trying kernel: nfs: task 10754 can't get a request slot kernel: nfs: server server.domain.name OK

    The "can't get a request slot" message means that the client-side RPC code has detected a lot of timeouts (perhaps due to network congestion, perhaps nfs error - 1 to error l1 closeclient invalid_socket windows server overloaded server), and is throttling back the number of concurrent outstanding requests in an attempt to lighten the load. The cause of these messages is basically sluggish performance. See Section 5, “Optimizing NFS Performance” for details.

  3. After mounting, the following message error on accept too many open files on the client: nfs warning: mount version older than kernel

    It means what it says: You should upgrade your mount package and/or am-utils. (If for some reason upgrading is a problem, you may be able to get away with just recompiling them so that the newer kernel features are recognized at compile time).

  4. Errors in startup/shutdown log for lockd nfslock: rpc.lockd startup failed

    They are harmless. Older versions of rpc.lockd needed to be started up manually, but newer versions are started automatically by nfsd. Many of the default startup scripts still try to start up lockd by hand, in case it is necessary. You can alter your startup scripts if you want the messages to go away.

  5. The following message appears in the logs: kmem_create: forcing size word alignment - nfs_fh This results from the file handle being 16 bits instead of a multiple of 32 bits, which makes the squid transparent ssl_error_rx_record_too_long grimace. It is harmless.

7.7. Real permissions don't match what's in /etc/exports

is very sensitive to whitespace - so the following statements are not the same:

/export/dir hostname(rw,no_root_squash) /export/dir hostname (rw,no_root_squash)

The first will grant hostname access to without squashing root privileges, nfs error - 1. The second will grant hostname privileges with root squash and it will grant everyone else read/write access, without squashing root privileges. Nice huh?

7.8. Flaky and unreliable behavior

Simple commands such as ls work, but anything that transfers a large amount of information causes the mount point to lock.

This could be one of two problems:

  1. It will happen if you have ipchains on at the server and/or the client and you are not allowing fragmented packets through the chains. Allow fragments from the remote host and you'll be able to function again. See Section 5, “Optimizing NFS Performance” for details on how to do this.
  2. You may be using a larger and in xen error disk isnt accessible mount options than the server supports. Try reducing and to 1024 and seeing if the problem goes away. If it does, then increase them slowly to a more reasonable value.

Check the file and make sure root has read permission. Check the binaries and make sure they are executable. Make sure your kernel was compiled with NFS server support. You may need to reinstall your binaries if none of these ideas helps, nfs error - 1.

7.10. File Corruption When Using Multiple Clients

If a file has been modified within one second of its previous modification and left the same size, it will continue to generate the same inode number. Because of this, nfs error - 1, constant reads and writes to a file by multiple clients may cause file corruption. Fixing this bug requires changes deep within the filesystem layer, and therefore it is a 2.5 nfs error - 1.

Next Glossary Contents nfs error - 1

Thematic video

[SOLVED] %1 is Not a Valid Win32 Application Error Issue

Nfs error - 1 - sorry

Contents

Environment

  • Red Hat Enterprise Linux (RHEL) 6, 7
  • NFS

Issue

  • Error is seen in the log:

Resolution

Note: Share should be unmounted from all the clients before making any configuration changes on the NFS server else the share will become stale

Root Cause

  • Reserved ports are TCP/UDP ports from to for privileged services and designated as well-known ports.

  • Below error was captured in log which means that NFS server requires a secure port:

Diagnostic Steps

  • NFS Server is pingable and able to to port and .
  • The command gets hung.
  • comes back with no shares available(blank)
  • Should appear with shares like so
  • displays list of all registered RPC programs. Verify that the needed services needed have the version being used (v3, v4, etc)
  • Try to mount with NFS version 3 but still it failed with error "access denied".
  • Check at NFS share that share is exported or not.
  • Tcpdump analysis:

The can not authenticate the NFS client.

  • Further analysis

indicates that the requester is not the owner. The operation was not allowed because the caller is neither a privileged user (root) nor the owner of the target of the operation.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

grep -v lofs' if [ "${ENTRY}" = "" ] ; then echo "Cannot find filesystem for devid ${FSID}" exit 1 fi set - ${ENTRY} MNTPNT=$2 INUM='echo "ibase=16;${INUMHEX}"

NFS Error Messages


Solution:

You must include a file name with the option. You cannot use directory names.


Description:

This message is often created when the services information in the namespace has not been updated. The message can also be reported for UDP.

Solution:

To fix this problem, you must update the services data in the namespace.

For NIS+, the entries should be as follows:


nfsd nfsd tcp 2049 NFS server daemon nfsd nfsd udp 2049 NFS server daemon

For NIS and , the entries should be as follows:


nfsd 2049/tcp nfs # NFS server daemon nfsd 2049/udp nfs # NFS server daemon

Solution:

Include the option with the option in the share command. You must define the public file handle in order for the option to work.


Note –

The Solaris 2.5.1 release required that the public file handle be set by using the command. A change in the Solaris 2.6 release sets the public file handle to be () by default. This error message is no longer relevant.



Description:

This message is displayed if the daemon terminates abnormally or if a system call error occurs. The string defines the problem.

Solution:

Contact Sun for assistance. This error message is rare and has no straightforward solution.


Description:

This message is displayed if the option is specified but the NFS server does not support the public file handle. In this situation, the mount fails.

Solution:

To remedy this situation, either try the mount request without using the public file handle or reconfigure the NFS server to support the public file handle.


Description:

The daemon is already running.

Solution:

If you want to run a new copy, kill the current version and start a new version.


Description:

This message is displayed when the that is associated with a daemon cannot be locked properly.

Solution:

Contact Sun for assistance. This error message is rare and has no straightforward solution.


Description:

This message is displayed when the that is associated with a daemon cannot be opened properly.

Solution:

Contact Sun for assistance. This error message is rare and has no straightforward solution.


Description:

This message is displayed on the console when a failover occurs. The message is advisory only.

Solution:

No action required.


Description:

An NFS version 2 client is trying to access a file that is over 2 Gbytes.

Solution:

Avoid using NFS version 2. Mount the file system with version 3 or version 4. Also, see the description of the option in Options for NFS File Systems.


Description:

The server that is sharing the file system you are trying to mount is down or unreachable, at the wrong run level, or its is dead or hung.

Solution:

Wait for the server to reboot. If the server is hung, reboot the server.


Description:

The mount request registered with , but the NFS mount daemon is not registered.

Solution:

Wait for the server to reboot. If the server is hung, reboot the server.


Description:

Either the remote directory or the local directory does not exist.

Solution:

Check the spelling of the directory names. Run on both directories.


Description:

Your computer name might not be in the list of clients or netgroup that is allowed access to the file system you tried to mount.

Solution:

Use to verify the access list.


Description:

An NFS version 4 server can delegate the management of a file to a client. This message indicates that the server is recalling a delegation for another client that conflicts with a request from your client.

Solution:

The recall must occur before the server can process your client's request. For more information about delegation, refer to Delegation in NFS Version 4.


Description:

This error can be caused by many situations. One of the most difficult situations to debug is when this problem occurs because a user is in too many groups. Currently, a user can be in no more than 16 groups if the user is accessing files through NFS mounts.

Solution:

An alternate does exist for users who need to be in more than 16 groups. You can use access control lists to provide the needed access privileges if you run at minimum the Solaris 2.5 release on the NFS server and the NFS clients.


Description:

The flag is not valid.

Solution:

Refer to the mount_nfs(1M) man page to verify the required syntax.


Note –

This error message is not displayed when running any version of the command that is included in a Solaris release from 2.6 to the current release or in earlier versions that have been patched.



Description:

An NFS client has attempted to mount a file system from an NFS server by using the option.

Solution:

This option is not supported for NFS file system types.


Description:

The NFS version 2 protocol cannot handle large files.

Solution:

You must use version 3 or version 4 if access to large files is required.


Description:

If programs hang while doing file-related work, your NFS server might have failed. This message indicates that NFS server is down or that a problem has occurred with the server or the network.

Solution:

If failover is being used, is a list of servers. Start troubleshooting with How to Check Connectivity on an NFS Client.


Description:

During part of the NFS version 4 server reboot, some operations were not permitted. This message indicates that the client is waiting for the server to permit this operation to proceed.

Solution:

No action required. Wait for the server to permit the operation.


Description:

This message is displayed by the , , and commands for the following reasons:

  • If the user or group that exists in an access control list (ACL) entry on an NFS version 4 server cannot be mapped to a valid user or group on an NFS version 4 client, the user is not allowed to read the ACL on the client.

  • If the user or group that exists in an ACL entry that is being set on an NFS version 4 client cannot be mapped to a valid user or group on an NFS version 4 server, the user is not allowed to write or modify an ACL on the client.

  • If an NFS version 4 client and server have mismatched NFSMAPID_DOMAIN values, ID mapping fails.

For more information, see ACLs and in NFS Version 4.

Solution:

Do the following:

  • Make sure that all user and group IDs in the ACL entries exist on both the client and server.

  • Make sure that the value for NFSMAPID_DOMAIN is set correctly in the file. For more information, see Keywords for the File.

To determine if any user or group cannot be mapped on the server or client, use the script that is provided in Checking for Unmapped User or Group IDs.


Description:

The port number that is included in the NFS URL must match the port number that is included with the option to mount. If the port numbers do not match, the mount fails.

Solution:

Either change the command to make the port numbers identical or do not specify the port number that is incorrect. Usually, you do not need to specify the port number with both the NFS URL and the option.


Description:

For NFS failover to function properly, the NFS servers that are replicas must support the same version of the NFS protocol.

Solution:

Running multiple versions is not allowed.


Description:

NFS failover does not work on file systems that are mounted read-write. Mounting the file system read-write increases the likelihood that a file could change.

Solution:

NFS failover depends on the file systems being identical.


Description:

Replicated mounts require that you wait for a timeout before failover occurs.

Solution:

The option requires that the mount fail immediately when a timeout starts, so you cannot include the option with a replicated mount.


Solution:

Check that the file has only one file system selected to be shared with the option. Only one public file handle can be established per server, so only one file system per server can be shared with this option.


Description:

An NFS client has unsuccessfully attempted to establish a connection with the network lock manager on an NFS server. Rather than fail the mount, this warning is generated to warn you that locking does not work.

Solution:

Upgrade the server with a new version of the OS that provides complete lock manager support.

7. Troubleshooting

7.1. Unable to See Files on a Mounted File System

First, check to see if the file system is actually mounted. There are several ways of doing this. The most reliable way is to look at the file , which will list all mounted filesystems and give details about them. If this doesn't work (for example if you don't have the filesystem compiled into your kernel), you can type although you get less information.

If the file system appears to be mounted, then you may have mounted another file system on top of it (in which case you should unmount and remount both volumes), or you may have exported the file system on the server before you mounted it there, in which case NFS is exporting the underlying mount point (if so then you need to restart NFS on the server).

If the file system is not mounted, then attempt to mount it. If this does not work, see Symptom 3.

7.3. Unable to mount a file system

There are two common errors that mount produces when it is unable to mount a volume. These are:

  1. failed, reason given by server:

    This means that the server does not recognize that you have access to the volume.

    1. Check your file and make sure that the volume is exported and that your client has the right kind of access to it. For example, if a client only has read access then you have to mount the volume with the option rather than the option.

    2. Make sure that you have told NFS to register any changes you made to since starting nfsd by running the exportfs command. Be sure to type exportfs -ra to be extra certain that the exports are being re-read.

    3. Check the file and make sure the volume and client are listed correctly. (You can also look at the file for an unabridged list of how all the active export options are set.) If they are not, then you have not re-exported properly. If they are listed, make sure the server recognizes your client as being the machine you think it is. For example, you may have an old listing for the client in that is throwing off the server, or you may not have listed the client's complete address and it may be resolving to a machine in a different domain. One trick is login to the server from the client via ssh or telnet; if you then type who, one of the listings should be your login session and the name of your client machine as the server sees it. Try using this machine name in your entry. Finally, try to ping the client from the server, and try to ping the server from the client. If this doesn't work, or if there is packet loss, you may have lower-level network problems.

    4. It is not possible to export both a directory and its child (for example both and ). You should export the parent directory with the necessary permissions, and all of its subdirectories can then be mounted with those same permissions.

  2. : (or another "RPC" error):

    This means that the client does not detect NFS running on the server. This could be for several reasons.

    1. First, check that NFS actually is running on the server by typing rpcinfo -p on the server. You should see something like this:

      This says that we have NFS versions 2 and 3, rpc.statd version 1, network lock manager (the service name for rpc.lockd) versions 1, 3, and 4. There are also different service listings depending on whether NFS is travelling over TCP or UDP. UDP is usually (but not always) the default unless TCP is explicitly requested.

      If you do not see at least , , and , then you need to restart NFS. If you are not able to restart successfully, proceed to Symptom 9.

    2. Now check to make sure you can see it from the client. On the client, type rpcinfo -p server where server is the DNS name or IP address of your server.

      If you get a listing, then make sure that the type of mount you are trying to perform is supported. For example, if you are trying to mount using Version 3 NFS, make sure Version 3 is listed; if you are trying to mount using NFS over TCP, make sure that is registered. (Some non-Linux clients default to TCP). Type for more details on how to read the output. If the type of mount you are trying to perform is not listed, try a different type of mount.

      If you get the error , then you need to check your and files on the server and make sure your client actually is allowed access. Again, if the entries appear correct, check (or your DNS server) and make sure that the machine is listed correctly, and make sure you can ping the server from the client. Also check the error logs on the system for helpful messages: Authentication errors from bad entries will usually appear in , but may appear somewhere else depending on how your system logs are set up. The man pages for can help you figure out how your logs are set up. Finally, some older operating systems may behave badly when routes between the two machines are asymmetric. Try typing tracepath [server] from the client and see if the word "asymmetric" shows up anywhere in the output. If it does then this may be causing packet loss. However asymmetric routes are not usually a problem on recent linux distributions.

      If you get the error , but you can ping the server correctly, then you are the victim of an overzealous firewall. Check any firewalls that may be set up, either on the server or on any routers in between the client and the server. Look at the man pages for ipchains, netfilter, and ipfwadm, as well as the IPChains-HOWTO and the Firewall-HOWTO for help.

7.4. I do not have permission to access files on the mounted volume.

This could be one of two problems.

If it is a write permission problem, check the export options on the server by looking at and make sure the filesystem is not exported read-only. If it is you will need to re-export it read/write (don't forget to run exportfs -ra after editing ). Also, check and make sure the volume is mounted read/write (although if it is mounted read-only you ought to get a more specific error message). If not then you need to re-mount with the option.

The second problem has to do with username mappings, and is different depending on whether you are trying to do this as root or as a non-root user.

If you are not root, then usernames may not be in sync on the client and the server. Type id [user] on both the client and the server and make sure they give the same UID number. If they don't then you are having problems with NIS, NIS+, rsync, or whatever system you use to sync usernames. Check group names to make sure that they match as well. Also, make sure you are not exporting with the option. If the user names match then the user has a more general permissions problem unrelated to NFS.

If you are root, then you are probably not exporting with the option; check or on the server and make sure the option is listed. In general, being able to write to the NFS server as root is a bad idea unless you have an urgent need -- which is why Linux NFS prevents it by default. See Section 6 for details.

If you have root squashing, you want to keep it, and you're only trying to get root to have the same permissions on the file that the user nobody should have, then remember that it is the server that determines which uid root gets mapped to. By default, the server uses the UID and GID of nobody in the file, but this can also be overridden with the and options in the file. Make sure that the client and the server agree about which UIDnobody gets mapped to.

7.6. Strange error or log messages

  1. Messages of the following format:

    These happen when a NFS operation is attempted on a file you don't have write access to. The messages are harmless.

  2. The following messages frequently appear in the logs:

    The "can't get a request slot" message means that the client-side RPC code has detected a lot of timeouts (perhaps due to network congestion, perhaps due to an overloaded server), and is throttling back the number of concurrent outstanding requests in an attempt to lighten the load. The cause of these messages is basically sluggish performance. See Section 5 for details.

  3. After mounting, the following message appears on the client:

    It means what it says: You should upgrade your mount package and/or am-utils. (If for some reason upgrading is a problem, you may be able to get away with just recompiling them so that the newer kernel features are recognized at compile time).

  4. Errors in startup/shutdown log for lockd

    You may see a message of the following kind in your boot log:

    They are harmless. Older versions of rpc.lockd needed to be started up manually, but newer versions are started automatically by nfsd. Many of the default startup scripts still try to start up lockd by hand, in case it is necessary. You can alter your startup scripts if you want the messages to go away.

  5. The following message appears in the logs:

    This results from the file handle being 16 bits instead of a mulitple of 32 bits, which makes the kernel grimace. It is harmless.

7.7. Real permissions don't match what's in .

is very sensitive to whitespace - so the following statements are not the same:

The first will grant access to without squashing root privileges. The second will grant privileges with and it will grant everyoneelse read/write access, without squashing root privileges. Nice huh?

7.8. Flaky and unreliable behavior

Simple commands such as ls work, but anything that transfers a large amount of information causes the mount point to lock.

This could be one of two problems:

  1. It will happen if you have ipchains on at the server and/or the client and you are not allowing fragmented packets through the chains. Allow fragments from the remote host and you'll be able to function again. See Section 6.4 for details on how to do this.

  2. You may be using a larger and in your mount options than the server supports. Try reducing and to 1024 and seeing if the problem goes away. If it does, then increase them slowly to a more reasonable value.

7.9. nfsd won't start

Check the file and make sure root has read permission. Check the binaries and make sure they are executable. Make sure your kernel was compiled with NFS server support. You may need to reinstall your binaries if none of these ideas helps.

7.10. File Corruption When Using Multiple Clients

If a file has been modified within one second of its previous modification and left the same size, it will continue to generate the same inode number. Because of this, constant reads and writes to a file by multiple clients may cause file corruption. Fixing this bug requires changes deep within the filesystem layer, and therefore it is a 2.5 item.

Glossary

0 Comments

Leave a Comment