<div dir="ltr">The chmod commands allowed X2Go to open. So perhaps not a bug per se but a suggestion to improve on some error checking.<div><br></div><div>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.<br><br>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.<br><br>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.<br></div><div><br></div><div>Thanks for all of your suggestions in getting this to work.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 2, 2023 at 3:52 AM <<a href="mailto:me@jcn50.com">me@jcn50.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It could be a bug: the version distributed with Fedora 37 is <br>
4.1.0.3-19.fc37.x86_64.rpm whereas the one in CentOS 8 is <br>
x2goserver-4.1.0.3-17.el8.1.x86_64.rpm , with this showing in the change <br>
log:<br>
<br>
2022-07-23 - Fedora Release Engineering <<a href="mailto:releng@fedoraproject.org" target="_blank">releng@fedoraproject.org</a>> - <br>
4.1.0.3-19<br>
- Rebuilt for <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Fedora-5F37-5FMass-5FRebuild&d=DwIDaQ&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=c4doz1suIijY2NueNOG6O9qnEmjwZUxxuWDG4ja3upV5tc8ZxcyS12WTuJJIWT3F&s=L9tIePHQQsnuZYnxUL9fh-gQnR4Rx0oKIVntrG7c-LE&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Fedora-5F37-5FMass-5FRebuild&d=DwIDaQ&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=c4doz1suIijY2NueNOG6O9qnEmjwZUxxuWDG4ja3upV5tc8ZxcyS12WTuJJIWT3F&s=L9tIePHQQsnuZYnxUL9fh-gQnR4Rx0oKIVntrG7c-LE&e=</a> <br>
2022-05-30 - Jitka Plesnikova <<a href="mailto:jplesnik@redhat.com" target="_blank">jplesnik@redhat.com</a>> - 4.1.0.3-18<br>
- Perl 5.36 rebuild<br>
<br>
Those are the permissions I have on my side (on Debian 11 but it should <br>
be the same):<br>
root@dev:~# ls -lah /var/lib/<br>
drwxrwx---+  2 x2gouser x2gouser 4.0K Dec 29 01:37 x2go<br>
<br>
root@dev:~# ls -lah /var/lib/x2go/<br>
-rw-rw----+  1 root     x2gouser  40K Dec 29 01:37 x2go_sessions<br>
<br>
So try this:<br>
sudo chmod 0770 /var/lib/x2go && sudo chown x2gouser:x2gouser <br>
/var/lib/x2go && sudo chmod 0660 /var/lib/x2go/x2go_sessions && sudo <br>
chown root:x2gouser /var/lib/x2go/x2go_sessions && echo "PERMISSIONS <br>
FIXED"<br>
<br>
If it still doesn't work: maybe you can revert to version <br>
x2goserver-4.1.0.3-17 ? I tried to find the package for Fedora 37 but <br>
could only find the el8 ones... Maybe this command would work:<br>
sudo dnf install x2goserver-4.1.0.3-17.fc37<br>
Otherwise, the only last option to test out would be to use the EPEL8 <br>
repo and install the x2goserver-4.1.0.3-17.el8 package...<br>
<br>
<br>
Regards,<br>
Chris,<br>
Quantum Hosting®.<br>
<br>
On 2023-01-02 02:26, Robert Kudyba wrote:<br>
> Well a hypothesis was tested with simply changing permissions as<br>
> follows X2Go launched:<br>
> <br>
> sudo chmod 777 /var/lib/x2go<br>
> pascal:~/$ sudo chmod 666 /var/lib/x2go/x2go_sessions<br>
> <br>
> Is x2go_sessions is needed after a session is up and running?<br>
> <br>
> This proves that it is a problem of permission to read and write the<br>
> db.  Permission should be gotten via the sgid wrapper, but for some<br>
> reason it is not.<br>
> <br>
> Uninstalling and reinstalling did not work.<br>
>  Is there a script to fix permissions correctly? Should we remove the<br>
> x2go user and group and re-add?<br>
> <br>
> On Sun, Jan 1, 2023, 2:33 PM <<a href="mailto:me@jcn50.com" target="_blank">me@jcn50.com</a>> wrote:<br>
> <br>
>> Hi again Robert,<br>
>> <br>
>> I have tried (and succeeded) on a server using AlmaLinux 8 (I don't<br>
>> have<br>
>> access to Fedora 37, sorry) and this is the command I used (you<br>
>> might<br>
>> skip the 2x "epel" commands?):<br>
>> <br>
>> dnf upgrade -y && dnf install<br>
>> <br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__dl.fedoraproject.org_pub_epel_epel-2Drelease-2Dlatest-2D8.noarch.rpm&d=DwIDaQ&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=7p_4VYLAUDElk8vMZgdq0Z9McN077vuO0VabguwetT409bSXJvY1JoGQ0Pc6wHog&s=zksEEUIvkzgtDnM8715wOsqYfM21ArqKZhRQdldhWWA&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__dl.fedoraproject.org_pub_epel_epel-2Drelease-2Dlatest-2D8.noarch.rpm&d=DwIDaQ&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=7p_4VYLAUDElk8vMZgdq0Z9McN077vuO0VabguwetT409bSXJvY1JoGQ0Pc6wHog&s=zksEEUIvkzgtDnM8715wOsqYfM21ArqKZhRQdldhWWA&e=</a><br>
>> <br>
>> -y && dnf config-manager --enable epel && dnf config-manager<br>
>> --set-enabled powertools && dnf install -y xfdesktop gtk-doc xfce*<br>
>> --exclude=xfce4-sensors-plugin-devel lightdm firefox x2goserver<br>
>> x2goserver-xsession && systemctl isolate graphical.target &&<br>
>> systemctl<br>
>> set-default graphical.target && echo "PLEASE REBOOT NOW"<br>
>> <br>
>> Pausing and resuming the session didn't work though (probably bec my<br>
>> 1x<br>
>> CPU and 768 MB RAM are too small!).<br>
>> <br>
>> Again: I really prefer the LXQt or LXDE on Ubuntu/Debian as it is a<br>
>> lot<br>
>> faster than XFDE...(I can't imagine how slow MATE could be!).<br>
>> <br>
>> Regards,<br>
>> Chris,<br>
>> Quantum Hosting®.<br>
</blockquote></div>