Score:2

"WARNING: cannot create user data directory: cannot determine SELinux status: failed to obtain SELinux mount path" warning by snap

de flag

I'm running Ubuntu 20.04 on WSL2, and whenever I run helm I get the following warning:

cmd_run.go:1046: WARNING: cannot create user data directory: cannot determine SELinux status: failed to obtain SELinux mount path: incorrect number of tail fields, expected 3 but found 4

Searching for this error has not produced anything meaningful. How can I get rid of this warning?

Ubuntu version:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal

Helm version (warnings removed):

$ helm version
version.BuildInfo{Version:"v3.10.1", GitCommit:"9f88ccb6aee40b9a0535fcc7efea6055e1ef72c9", GitTreeState:"clean", GoVersion:"go1.18.7"}

I've also reported this as an issue to helm, and a collaborator thinks it has to do with snap, and not necessarily helm.

So I ran helm with SNAP_CONFINE_DEBUG=yes, and this is the output I got:

$ SNAP_CONFINE_DEBUG=yes helm ls
2023/04/14 02:34:53.395489 system_key.go:129: cannot determine nfs usage in generateSystemKey: cannot parse mountinfo: incorrect number of tail fields, expected 3 but found 4
2023/04/14 02:34:53.399251 cmd_run.go:1046: WARNING: cannot create user data directory: cannot determine SELinux status: failed to obtain SELinux mount path: incorrect number of tail fields, expected 3 but found 4
DEBUG: -- snap startup {"stage":"snap-confine enter", "time":"1681419893.460473"}
DEBUG: umask reset, old umask was  022
DEBUG: security tag: snap.helm.helm
DEBUG: executable:   /snap/snapd/18596/usr/lib/snapd/snap-exec
DEBUG: confinement:  classic
DEBUG: base snap:    core18
DEBUG: ruid: 1000, euid: 0, suid: 0
DEBUG: rgid: 1000, egid: 1000, sgid: 1000
DEBUG: apparmor extensions to the system are not available
DEBUG: -- snap startup {"stage":"snap-confine mount namespace start", "time":"1681419893.461157"}
DEBUG: preparing classic execution environment
DEBUG: -- snap startup {"stage":"snap-confine mount namespace finish", "time":"1681419893.461195"}
DEBUG: set_effective_identity uid:1000 (change: yes), gid:1000 (change: yes)
DEBUG: creating user data directory: /home/samslk/snap/helm/372
DEBUG: ruid: 1000, euid: 1000, suid: 0
DEBUG: setting capabilities bounding set
DEBUG: regaining SYS_ADMIN
DEBUG: loading bpf program for security tag snap.helm.helm
DEBUG: read 14 bytes from /var/lib/snapd/seccomp/bpf//snap.helm.helm.bin
DEBUG: clearing SYS_ADMIN
DEBUG: execv(/snap/snapd/18596/usr/lib/snapd/snap-exec, /snap/snapd/18596/usr/lib/snapd/snap-exec...)
DEBUG:  argv[1] = helm
DEBUG:  argv[2] = ls
DEBUG: umask restored to  022
DEBUG: working directory restored to /home/samslk/experiments/misc/helm-tutorial
DEBUG: -- snap startup {"stage":"snap-confine to snap-exec", "time":"1681419893.461324"}

...normal helm output from this point onwards

So it indeed looks like the warnings are coming from snap, as the helm executable is not started by snap until later.

How can I fix/suppress this?

cn flag
it is a warning not an error. warnings are intended for maintainers of software so you can ignore it. It would be best to report this against the helm package. Just make sure helm is supported on wsl ;)
sampathsris avatar
de flag
Thanks @Rinzwind. Yes, it's a warning, sure. But it clutters the output and it's such a PITA. Maybe I will file an issue with helm.
cn flag
does helm neet to output anything else? if not redirect to /dev/null
sampathsris avatar
de flag
@Rinzwind it does, unfortunately. The output of all helm commands is really important.
Score:2
de flag

In the end I had to remove helm from snap.

sudo snap remove helm

And installed it using the script as described in helm documentation:

# This command may change for the helm version.
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

And it worked like a charm. Unfortunately I could not find what was wrong with snap.

P.S. Also, redirecting error output (e.g.: helm .... 2>/dev/null) was not an option, as it would also suppress valuable error messages from helm itself.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.