#Unable to connect to engine with version 0.7.0

1 messages · Page 1 of 1 (latest)

storm nacelle
#

Hi, moving to new 0.7.0 version with vscode user i got:

Error: progress forwarding: mkdir /run/user: permission denied

With root user it works correctly

My dev environment is windows 11 with rancher desktop and vscode/devcontainer (docker outside docker)

Do i need to connect in a different way ?

#

I can fix with sudo chown -R vscode /run/user sudo chgrp -R vscode /run/user

kindred root
#

👋 seems like a particular exception in devcontainers. Dagger uses $XDG_RUNTIME_DIR/dagger directory to create some UDS for management purposes. You need to check how you can set permissions so your devoconainer can write there

wary moat
#

I actually hit this too but figured I was doing something weird in my dev env, maybe it's more common though. It should be fixable on our end, I think we can fallback to using XDG_RUNTIME_HOME if XDG_RUNTIME_DIR doesn't have the needed permissions. I can try implementing that quick

wary moat
kindred root
trail badger
#

this will likely solve issues for us podman Ostree users

gritty summit
#

Should this be the case when not using the TUI? I am simply doing go run main.go but I am seeing this same behavior. I am running within Jenkins so I can't use TUI.

#

Our Jenkins is hosted in EKS and has "no new privileges" flag.

kindred root
gritty summit
#

I am saying it is :). My only option in Jenkins is running without TUI

kindred root
gritty summit
#

This is what I'm seeing

Error: progress forwarding: mkdir /run/user/1000: permission denied

My user is jenkins and uid:gid is 1000:1000. And I don't have the ability to elevate. But I am in a dind image so it's running as privileged. I didn't have the issue with the previous engine v0.5.3

#

So, dagger is trying to write to that folder and it can't

#

I just reverted back to v0.5.3 and gosdk 0.6.3 and the build is running fine, so nothing has changed on my end

heavy smelt
kindred root
gritty summit
#

I did upgrade and the issue is gone away. I saw that the fix came with a warning

"This adds a fallback to use the home cache dir in such cases. This isn't as ideal since that dir isn't a tmpfs, but is better than failing I think. A warning is printed when this happens to let users know."

I am assuming that is expected/true for all CI platforms that run this? Because they don't have the ability to run the TUI. For my understanding, why is the dir vs tmpfs not ideal? Is it performance related? Or in terms of avoiding collisions?

#

I am also not seeing the above warning in my logs.

kindred root
#

FWIW that change is not exclusively related to the TUI. It's useful for any other process which wants to consume real-time events of the engine