Turbo VNC errors while running linuxhost adapter based jobs

Hi,

It appears that I’ve started receiving vnc errors while running singularity based linuxhost jobs after upgrading from 2.0.0 > 2.0.10 > 2.0.13. turbovncserver-security.conf is owned by root and readable by all so I’m wondering if this is a UID related issue inside of the singularity pid space or something else. Note this same error is occurring with all linuxhost based jobs that previously worked with the caveat that the system’s OS has been rebuilt through each OOD upgrade cycle via salt. (i.e. it’s possible a component outside of OOD has been updated) Has anyone run into this issue?

(EE)
Fatal server error:
(EE) ERROR: /opt/TurboVNC/etc/turbovncserver-security.conf must be owned by you or by root(EE)

TurboVNC Server (Xvnc) 64-bit v2.2.5 (build 1.el7)
Copyright (C) 1999-2020 The VirtualGL Project and many others (see README.txt)
Visit http://www.TurboVNC.org for more information on TurboVNC

(EE)
Fatal server error:
(EE) ERROR: /opt/TurboVNC/etc/turbovncserver-security.conf must be owned by you or by root(EE)
TurboVNC Server (Xvnc) 64-bit v2.2.5 (build 1.el7)
Copyright (C) 1999-2020 The VirtualGL Project and many others (see README.txt)
Visit http://www.TurboVNC.org for more information on TurboVNC

job script options

{
“job_name”: “sys/dashboard/sys/webbrowser-linuxhost”,
“workdir”: “/home/jflilley/ondemand/data/sys/dashboard/batch_connect/sys/webbrowser-linuxhost/output/9f9da789-56ed-4ece-9dc3-c1bd279e4257”,
“output_path”: “/home/jflilley/ondemand/data/sys/dashboard/batch_connect/sys/webbrowser-linuxhost/output/9f9da789-56ed-4ece-9dc3-c1bd279e4257/output.log”,
“shell_path”: “/bin/bash”,
“native”: {
“singularity_bindpath”: “/etc,/media,/mnt,/opt,/run,/srv,/usr,/var,/central/home,/central/software,/central/groups”,
“singularity_container”: “/central/software/singularity/images/centos7-stock.sif”
}
}

On a related note, does OOD still plan to remove the singularity requirement from linuxhost jobs via unshare?

For reference the issue was the vnc security file being too open (i.e. it was owned by root but also allowed read by anyone). Changing the file permission to 600 or changing the singularity from 3.x to 2.x bypassed the issue.