The chmod commands allowed X2Go to open. So perhaps not a bug per se but a suggestion to improve on some error checking.
We still use NIS/yp (yes it's ok to groan). The NIS server included the x2gouser GID in /etc/group. This led to creation of the user when x2go was installed adopting that GID (461) in /etc/passwd instead of the one that the installation created (973) in /etc/group. (Thus /etc/passwd had x2gouser:x:977:461 while /etc/group had x2gouser:x:973.) The GID of the setgid program /usr/lib64/x2go/libx2go-server-db-sqlite3-wrapper was the one in /etc/group, namely 973, while the GID of /var/lib/x2go and /var/lib/x2go/x2go_sessions was the one in /etc/passwd, namely 461. Hence when the process adopted the GID 973 of the wrapper, it was not granted access to files with GID 461.
This caused any of the x2go library scripts that access the database to fail when run as a normal user, In practice, the first one that is run as a session is starting is x2gogetports, which returned a "cannot open file" error message instead of a list of port numbers. This error message (or more precisely the first "word" of it) was fed to x2gocheckports at line 131, which tried to interpret it as a port number, and got a syntax error as a result.
In fact, there are many ways that the x2go server process could fail to open the database file. All of them will generate the exact same error message. If I may suggest a change, it would be to catch these errors earlier (e.g. by a success code from x2gogetports and its kin) and report the file open failure with a message based on the errno, (e.g. no such file or access denied). This would narrow down the possible causes of the failure.
Thanks for all of your suggestions in getting this to work.