I believe you just need to update /etc/apparmor.d/usr.bin.man to include all of the necessary MAN paths.
This was a bug in apparmor that supposedly has been fixed, but depending on your patch level, it may not. Anyway, according to the bug filed here: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1784499 this is the fix for man pages: Workaround (for /usr/bin/man only): Add to /etc/apparmor.d/local/usr.bin.man the lines # TCP/UDP network access for NFS network inet stream, network inet6 stream, network inet dgram, network inet6 dgram, then run # systemctl reload apparmor On Fri, Jan 25, 2019 at 9:24 AM David Triimboli <trimb...@cshl.edu> wrote: > On 1/25/2019 11:02 AM, Fred Youhanaie wrote: > > On 25/01/2019 14:24, David Triimboli wrote: > >> On 1/24/2019 5:25 PM, Fred Youhanaie wrote: > >>> > >>> 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, > > > > I think that's just the man command trying to be smart and guess the > > man page pathname based on the pathname of the qhost command. > > > I was thinking that too, based on other lines. > > > > >>> 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 was suspecting selinux, but it seems it's apparmor instead. > > > I made sure selinux was disabled before starting any of this. I've been > burned before. > > > > >> I tried stopping the AppArmor service and running "man qhost" again, > >> but it made no difference. > > > > I don't think stopping the service would have helped, you may need to > > unload/fix the apparmor profiles already loaded in the kernel. > > > > I haven't worked with apparmor, so you may need to search the internet > > for solutions. > > > I'll take a look. My brief perusal suggests that it's a nontrivial task > to do so. I'll see what I find. > > Thanks! > > _______________________________________________ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users > -- Ian Kaufman Research Systems Administrator UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu
_______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
