The latest version which requires a password in the gui_rpc_auth.cfg file sure is causing lots of troubles it seems from the plethora of posts for help lately.

I've commented on the PR that did this, #3709, so let's see if there's any other comments on this than "yes, but it's more secure this way".

---

/Quote You should see the client start and print out the normal startup messages.
If that doesn't work, then navigate to /usr/bin and open a Terminal and try running the client executable directly there, without starting the service. Should see the standard client startup messages.

First one didnt work at all

Second one gave me this error
gui_rpc_auth.cfg not found. Try reinstalling BOINC

Since the second one didnt work didnt run the third.

And I am having this problem Installing and running BOINC from the Ubuntu Software app. on 20.04 i just typed in BOINC and installed it then ran it. It ran fine and let me set it up for my project. Obviously there is a problem this time, that needs to be fixed.

Can you check that you have a symlink for gui_rpc_auth.cfg in /var/lib/boinc-client pointing to /etc/boinc-client for the file?
The symlink in /var/lib/boinc-client should have root:root ownership.
The file in /etc/boinc-client should have root:boinc ownership.
Can you verify that your user belongs to group boinc?

So, the boinc distro in Ubuntu 20.04 LTS runs with no issues?

So, what the heck did the Ubuntu 20.10 packagers do to the boinc package in that distro that completely changed the way boinc is installed?

The latest version which requires a password in the gui_rpc_auth.cfg file sure is causing lots of troubles it seems from the plethora of posts for help lately.

I've commented on the PR that did this, #3709, so let's see if there's any other comments on this than "yes, but it's more secure this way".

Yes, certainly more secure as BOINC is unable to run in the first place.

Kusho, I agree. I did all those things, and still get the same error.

Peter

Keith Myers,

Yes to first four, so far as I can tell.

Peter

Just realised why upgrading to 20.10 hasn't screwed things up for me. - Rolled my own from source on a clean install of 20.04 so Ubuntu hasn't tried to update me. (most probably say it is too late for that anyway!)

When the work on older laptop is cleared, will do a clean install of 20.10 and then enjoy the finding of all the prerequisite libraries again to do the same there.

The latest version which requires a password in the gui_rpc_auth.cfg file sure is causing lots of troubles it seems from the plethora of posts for help lately.

I've commented on the PR that did this, #3709, so let's see if there's any other comments on this than "yes, but it's more secure this way".

I was tempted to add "as I predicted in the very first comment on that PR". But I decided that - because David seems to switch off whenever he sees my name - it would probably be counterproductive.

EUREKA!
I was forced, for other reasons, to do a full "button" reboot.

And....
BOINC IS WORKING!

So, if all else fails, use the Index Finger and see what happens.

Peter

For those who like me don't remember all the permission numbers. this may be useful.

Number Permission Type Symbol
0 No Permission —
1 Execute –x
2 Write -w-
3 Execute + Write -wx
4 Read r–
5 Read + Execute r-x
6 Read + Write rw-
7 Read + Write + Execute rwx

So, if all else fails, use the Index Finger and see what happens.

Congratulations - though I must confess I'm sometimes tempted to raise the middle finger instead...

For reference next time, this is my monthly (or thereabouts) maintenance routine.

1. sudo systemctl stop boinc-client
2. sudo systemctl disable boinc-client
3. Install all the pending Linux updates that have accumulated
4. Perform a full cold reboot of the machine
5. Wait until everything has stopped moving, and I can see my normal stable desktop
6. sudo systemctl enable boinc-client
7. sudo systemctl start boinc-client

Notes:
2,6: The disable/enable commands are to delay the BOINC auto-start. I run GPUs, and the system updates normally include a new kernel and a new video driver. Unless these are given time to sort themselves out after the reboot, BOINC can't find the GPUs, and can't run GPU tasks.
4: I normally perform a software restart from the start menu, but your finger may come in useful here.

I just went through this boinc manager problem on popos upgrading to 20.10
boinc-client.service would run fine, but Bonic Manager wouldn't connect to it. The manager was able to connect to remote machines.

Solution:
1) add my user to the boinc group (again?)
2) put some text into the empty /etc/boinc-client/gui_rpc_auth.cfg

note: /etc/boinc-client/gui_rpc_auth.cfg is symlinked to /var/lib/boinc-client/gui_rpc_auth.cfg

The latest version which requires a password in the gui_rpc_auth.cfg file sure is causing lots of troubles it seems from the plethora of posts for help lately.

I've commented on the PR that did this, #3709, so let's see if there's any other comments on this than "yes, but it's more secure this way".

I was tempted to add "as I predicted in the very first comment on that PR". But I decided that - because David seems to switch off whenever he sees my name - it would probably be counterproductive.

Now I know, weekend and all that, but there's very little acknowledgement coming from the dev team.

Now I know, weekend and all that, but there's very little acknowledgement coming from the dev team.

Monday, and thus far, zip.

I'd say, try BoincTUI, and see if that one gets access (terminal version of Manager, with slightly fewer options)

BOINCTUI also uses gui_rpc_auth.cfg. I will surmise every UI talking to the client via RPC will use gui_rpc_auth.cfg, so they will all have this problem.

---

Richard,

That makes perfect sense.

Let me guess that these can those be piped:
> sudo systemctl stop boinc-client | systemctl disable boinc-client
> etc
> sudo systemctl enable boinc-client | systemctl start boinc-client

Well, not so much. :-)
I just tried and it's not so good together.

So, I'll write out your suggestion into my "day book" for this system, with a big bar along the side and the page dog-eared so I can find it so easily.

Thanks,
Peter
https://en.wikipedia.org/wiki/Canberra
Home of https://en.wikipedia.org/wiki/Andrew_Tridgell who I've met and later interviewed for community radio....
and lurker at http://www.clug.org.au/

The latest version which requires a password in the gui_rpc_auth.cfg file sure is causing lots of troubles it seems from the plethora of posts for help lately.

I've commented on the PR that did this, #3709, so let's see if there's any other comments on this than "yes, but it's more secure this way".

I was tempted to add "as I predicted in the very first comment on that PR". But I decided that - because David seems to switch off whenever he sees my name - it would probably be counterproductive.

Well, he's responded, with a sort-of climbdown. But I still see problems ahead.

There are three cases:
1) Empty password. Manager will work, and you get a warning. That's fine.
2) You know what you're doing, and why. You've set a password, and set the Manager to run with it. That's fine too.
3) You didn't have a password, but now you have one of David's specials. The Manager doesn't work.

What's your way out of (3)? We can't just erase all passwords, because that would mightily annoy group (2), and they are probably people David thinks are important.

Once again, David has shown that he thinks in the present. But he doesn't think about edge cases, or about transitions from old to new. He's a coder - barely more than a hacker - but not a scientist or an analyst.

Hi everybody,

I've got the same problem as everybody (pb RPC connexion, no password, no gui_rpc_auth.cfg, etc.). After put a password and follow the maintenance routine of Richard (#101298), it finally works for me.

Thanks a lot.
Wil

Can you imagine the outcry if it were to be made that interesting (difficult) for Windows users?