> Am 25.01.2019 um 15:24 schrieb David Triimboli <trimb...@cshl.edu>:
>
> 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
In principle this could be masked by an ACL on the exporting machine. It's even
possible to mount the fiel system on the exechost without honoring the ACL and
wonder why one has no access (as the permission bits look fine). Essentially
the exporting NFS machine will deny the access according to certain bits of the
permission bits. Does the line form above contain a plus sign on the exporting
machine like:
-rwxr-xr-x+ 1 root root 1941408 Feb 28 2016 /opt/sge/bin/lx-amd64/qhost
-- Reuti
>
>>
>> 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
>
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
