LSF Version 7.3 - Platform LSF Configuration Reference

User permission denied
If remote execution fails with the following error message, the remote host could not securely
determine the user ID of the user requesting remote execution.
User permission denied.
Check the RES error log on the remote host; this usually contains a more detailed error
message.
If you are not using an identification daemon (LSF_AUTH is not defined in the lsf.conf
file), then all applications that do remote executions must be owned by root with the
setuid bit set. This can be done as follows.
chmod 4755 filename
If the binaries are on an NFS-mounted file system, make sure that the file system is not mounted
with the nosuid flag.
If you are using an identification daemon (defined in the lsf.conf file by LSF_AUTH),
inetd must be configured to run the daemon. The identification daemon must not be run
directly.
If LSF_USE_HOSTEQUIV=Y is defined in the lsf.conf file, check if /etc/
hosts.equiv or HOME/.rhosts on the destination host has the client host name in it.
Inconsistent host names in a name server with /etc/hosts and /etc/hosts.equiv can
also cause this problem.
On SGI hosts running a name server, you can try the following command to tell the host name
lookup code to search the /etc/hosts file before calling the name server.
setenv HOSTRESORDER "local,nis,bind"
For Windows hosts, users must register and update their Windows passwords using the
lspasswd command. Passwords must be 3 characters or longer and 31 characters or less.
For Windows password authentication in a non-shared file system environment, you must
define the parameter LSF_MASTER_LIST in lsf.conf so that jobs will run with correct
permissions. If you do not define this parameter, LSF assumes that the cluster uses a shared
file system environment.
Non-uniform file name space
A command may fail with the following error message due to a non-uniform file name space.
chdir(...) failed: no such file or directory
You are trying to execute a command remotely, where either your current working directory
does not exist on the remote host, or your current working directory is mapped to a different
name on the remote host.
If your current working directory does not exist on a remote host, you should not execute
commands remotely on that host.
On UNIX, if the directory exists, but is mapped to a different name on the remote host, you
have to create symbolic links to make them consistent.
LSF can resolve most, but not all, problems using automount. The automount maps must be
managed through NIS. Follow the instructions in your Release Notes for obtaining technical
Troubleshooting and error messages
Platform LSF Configuration Reference 599