Juju 3.0: cannot load ssh client keys: mkdir /home/ubuntu/.local: permission denied

[Bartlomiej Gmerek]

Hello Team,

After installing Juju 3.0 on a fresh AWS machine (Ubuntu 20.04), I'm getting following error when trying to execute any Juju command (juju clouds, juju status, etc):

ERROR cannot load ssh client keys: mkdir /home/ubuntu/.local: permission denied

If I install Juju 2.9 first and then upgrade to Juju 3.0 (snap switch and snap refresh), the problem is not there.

Thanks in advance for looking into it.

BR,
Bartek

[John A Meinel (jameinel)]

The issue is that 3.0 is a strictly confined snap, and is not allowed to
create ~/.local/share. You can install 3.0.0 directly, and just 'mkdir -p
~/.local/share' and then Juju 3.0 will also work. (We are working with
snapd to work through who should be ensuring that under strict confinement
who should actually be responsible for making sure parent directories
exist.)

On Fri, Nov 4, 2022 at 11:15 AM Bartlomiej Gmerek <
<email address hidden>> wrote:

> Public bug reported:
>
> Hello Team,
>
> After installing Juju 3.0 on a fresh AWS machine (Ubuntu 20.04), I'm
> getting following error when trying to execute any Juju command (juju
> clouds, juju status, etc):
>
> ERROR cannot load ssh client keys: mkdir /home/ubuntu/.local: permission
> denied
>
> If I install Juju 2.9 first and then upgrade to Juju 3.0 (snap switch
> and snap refresh), the problem is not there.
>
> Thanks in advance for looking into it.
>
> BR,
> Bartek
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1995697
>
> Title:
> Juju 3.0: cannot load ssh client keys: mkdir /home/ubuntu/.local:
> permission denied
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1995697/+subscriptions
>
>

[Bartlomiej Gmerek (gmerold)]

Thanks for replying, John.
I know I can create missing dir manually (that's what I did eventually). My only point here is that it's kinda surprising for the user and we could probably use some disclaimer in the documentation.
Anyway, let's close this ticket and continue in the other one.