Hi
Recently joined QuChemPedIA project to help my team in a crunching challenge.

My PC fits the criteria - Linux Mint 20.1 and BOINC 7.16.16 from a PPA - BUT I have now discovered that the PPA version 7.16.16 produces dud results!

So to fix I removed the old version. Removed the PPA from my sources list. Installed new version from the apt repository (7.16.6)

ALL is well, "top" command shows 16 boinc commands crunching away at 100% CPU. BUT when I start BOINC Manager - no tasks/projects are shown.

Can anyone help?

Your client is working obviously. Do you see a connected to localhost message in the bottom Manager status bar?

Nope, says it's disconnected.

If manager is disconnected it won't show any tasks. Try exiting the manager and then go to /var/lib/boinc-client in a terminal and executing

./run_manager

from there. If it still doesn't connect you should get a message in the terminal that will give some hints as to what is going on.

All good. A friend from the BOINC@AUSTRALIA forum pointed me in the right direction...

Open "File|Select Computer". Enter localhost and password from gui_rpc_auth.cfg file in /etc/boinc-client. All good! I can see my tasks again!

All good. A friend from the BOINC@AUSTRALIA forum pointed me in the right direction...

Open "File|Select Computer". Enter localhost and password from gui_rpc_auth.cfg file in /etc/boinc-client. All good! I can see my tasks again!

The saga of the changes to increase security carries on. I remain unconvinced that forcing users to either use root privileges/sudo even if only to open a file and find a password actually helps security at all at least on a home system. Clearly there may be reasons to stop the person sitting in front of a work computer from running things as they want.

The other, more permanent, way of fixing this is to add the owner to the boinc security group:

sudo usermod -a -G boinc ownername

And reboot

The other, more permanent, way of fixing this is to add the owner to the boinc security group:

sudo usermod -a -G boinc ownername

And reboot

A cautionary tale, never try to perform updates from memory when your memory is as bad as mine.

I’ve just spent an interesting hour or so recovering my system having entered the above command and missing out the -a.

So instead of appending Boinc to the list of groups my user was a member of it replaced that list with just Boinc. The sole user on the machine was therefore no longer admin and had no sudo permissions.

It turned out that the root user is disabled by default in Ubuntu so I had no way to correct the problem.

I tried booting into a live session from usb but the system is too clever for that, it still would not give me access to system files.

I eventually managed to get into recovery mode once I worked out that the grub access key has changed from space to esc since last I used it. From there I checked the sudoers file thinking to add myself to the list but that was identical to my working system. Then I looked into the groups file and that’s where the changes had been made. It turns out that they don’t hold a list of groups you are part of and append new entries, it works the other way round and the entry for each group has a list of all subsidiary groups so I had to add my user to half a dozen entries (guided by the groups file on the working system).

I now know a lot more about the inner workings of group permissions but I’ll never make that mistake again - until the next time my memory goes awol :-)

Oooof, hard lesson to learn. Thanks for the cautionary tale.

This worked. Thanks!

The other, more permanent, way of fixing this is to add the owner to the boinc security group:

sudo usermod -a -G boinc ownername

And reboot

A cautionary tale, never try to perform updates from memory when your memory is as bad as mine.

I’ve just spent an interesting hour or so recovering my system having entered the above command and missing out the -a.

So instead of appending Boinc to the list of groups my user was a member of it replaced that list with just Boinc. The sole user on the machine was therefore no longer admin and had no sudo permissions.

It turned out that the root user is disabled by default in Ubuntu so I had no way to correct the problem.

I tried booting into a live session from usb but the system is too clever for that, it still would not give me access to system files.

I eventually managed to get into recovery mode once I worked out that the grub access key has changed from space to esc since last I used it. From there I checked the sudoers file thinking to add myself to the list but that was identical to my working system. Then I looked into the groups file and that’s where the changes had been made. It turns out that they don’t hold a list of groups you are part of and append new entries, it works the other way round and the entry for each group has a list of all subsidiary groups so I had to add my user to half a dozen entries (guided by the groups file on the working system).

I now know a lot more about the inner workings of group permissions but I’ll never make that mistake again - until the next time my memory goes awol :-)

Ouch. That's why I also copy and paste, then amend. Not totally foolproof but it saves me relying on my memory.

Ouch. That's why I also copy and paste, then amend. Not totally foolproof but it saves me relying on my memory.

I have root set up on my Ubuntu machines just in case I need it. Haven't needed it to date but know I very well might at some point.

Ouch. That's why I also copy and paste, then amend. Not totally foolproof but it saves me relying on my memory.

Trouble is, copy'n'paste with incomplete edit can be even worse...

#3249 fixes #3247.