Permissions problem using snapcraft in Azure Pipelines

Hello folks,

I’ve recently been running into some issues when trying to use snapcraft in an Azure Pipelines CI setup. As far as I can tell it’s related to a permissions problem related to snapd.

Installation works OK (sudo snap install --classic --stable snapcraft) but when the CI job tries to run snapcraft it emits an error:

+ snapcraft --version
/ not root-owned 1001:50
+ snapcraft
/ not root-owned 1001:50

The error is correct: / in the CI job is owned by vsts, not root (which I presume is a special user created by Azure Pipelines).

snapd itself is running as root, as one would expect.

Any advice on how to deal with this? I presume it’s a safety feature to prevent snapd from writing into directories it shouldn’t be able to, but in this case it appears to be coming up against a deliberate decision by Azure Pipelines that the root dir of the CI job should not be owned by the root user. (Most of its contents on the other hand are root-owned: all the usual system dirs.)

Having problems that is similar and likely the same error.

First a step is run with:

sudo apt update
sudo apt install snapd
sudo snap install --classic snapcraft

Then electron-builder is called with the snap flag, and it logs:

snapcraft is not installed, please: sudo snap install snapcraft --classic

Building the .snap itself works fine I think, it is simply the uploading with snapcraft that fails.

likely not … this is just a common mistake and we should somehow make sure some message is displayed from the snapd postinst script or so …

what happens is:

installs snapd and all the tools, creates /snap/bin and adds info about it to the login scripts that create your PATH variable during login …

installs /snap/bin/snapcraft

… does not find /snap/bin/snapcraft because the scripts above that craft your PATH variable only run at login time, so the rule of thumb after you installed the snapd deb is to log out and back in again, which will then make your PATH include /snap/bin and electron-builder will find the snapcraft binary …

this is unrelated to root filesystem permissions …

Thanks for the reply, logout and login is likely not a viable solution for a hosted build on Azure DevOps. Perhaps simply adding the PATH to include /snap/bin as a shell cmd in the process might be enough. Will do some testing and see.

Sorry for belated follow-up here – things got busy with the day job :wink:

My own azure pipelines setup is pretty simple:

- 1.*

- job: ldc2_snap
  timeoutInMinutes: 0
    vmImage: ubuntu-16.04
  - script: |
      set -x
      snap version
      lxd --version
      sudo apt-get update
      sudo snap install --classic --candidate snapcraft
      export PATH="${PATH}:/snap/bin"
      snapcraft --version
    displayName: Build ldc2 snap package

Note that this assumes that snapd is already installed (which seems reasonable and has always worked before), and it exports an updated PATH that includes /snap/bin (so there should be no difficulty finding the installed snapcraft). The problem in this case really does look like it’s down to permissions.

Adding PATH should solve your problem, yes

Your problem is certainly not related to PATH at all, but I will let the snapd team address this issue.

Hi, I have same problem in GitHub Actions:

Run snapcraft login --with ***
/ not root-owned 501:50
##[error]Process completed with exit code 1.