On 1/24/2019 5:25 PM, Fred Youhanaie wrote:
I can see "Permission denied" errors such as this one in the trace:
openat(AT_FDCWD, "/opt/sge/man",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 EACCES (Permission
denied)
I think it's worth revisiting the directory permissions, for each path
component individually
cd /opt
cd /opt/sge
cd /opt/sge/man
Everything looks correct to me:
trimboli@ubuntuclient2:~$ ls -ld /opt
drwxr-xr-x 4 root root 4096 Jan 23 16:55 /opt
trimboli@ubuntuclient2:~$ cd /opt
trimboli@ubuntuclient2:/opt$ ls -ld sge
drwxr-xr-x 14 sgeadmin sgeadmin 4096 Jan 24 13:28 sge
trimboli@ubuntuclient2:/opt$ cd sge
trimboli@ubuntuclient2:/opt/sge$ ls -ld man
drwxr-xr-x 10 sgeadmin sgeadmin 4096 Jan 23 16:03 man
trimboli@ubuntuclient2:/opt/sge$ cd man
trimboli@ubuntuclient2:
There are also lines like the following
stat("/opt/sge/bin/qhost", 0x7fff16f8c7a0) = -1 EACCES (Permission
denied)
That's a strange line, because qhost lives in /opt/sge/bin/lx-amd64. But
the following line also has a permission denied message, and it points
to the correct location of qhost. But of course,
trimboli@ubuntuclient2:/opt/sge$ ls -l /opt/sge/bin/lx-amd64/qhost
-rwxr-xr-x 1 root root 1941408 Feb 28 2016 /opt/sge/bin/lx-amd64/qhost
As already explored by Reuti and yourself, it looks like NFS related
in the /opt/sge components. Anything in the system log?
Hmm. Possibly, but it's beyond my ability to interpret. Here are a
couple of interesting things I found:
audit: type=1400 audit(1548425695.819:52): apparmor="DENIED"
operation="sendmsg" profile="/usr/bin/man" pid=3534 comm="man"
laddr=10.0.2.4 lport=878 faddr=10.0.2.15 fport=2049 family="inet"
sock_type="stream" protocol=6 requested_mask="send" denied_mask="send"
nfs: RPC call returned error 13
I tried stopping the AppArmor service and running "man qhost" again, but
it made no difference.
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
