-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues with VSCode Dev Containers Compatibility #18691
Comments
Error appears to be There's a @flouthoc PTAL |
Experiencing #17313 on my personal Intel Mac |
A friendly reminder that this issue had no activity for 30 days. |
I'm on Windows and installed Podman 4.6.0 And I'm facing different kind of error. Container log:
{
"name": "Node.js & TypeScript",
"image": "mcr.microsoft.com/devcontainers/typescript-node:18",
"postCreateCommand": "bash .devcontainer/setup.sh",
"features": {
"ghcr.io/devcontainers-contrib/features/typescript:2": {},
"ghcr.io/devcontainers/features/desktop-lite:1": {},
"ghcr.io/devcontainers/features/git:1": {},
"ghcr.io/devcontainers/features/node:1": {},
"ghcr.io/dhoeric/features/hadolint:1": {}
},
"customizations": {
"vscode": {
"extensions": [
"christian-kohler.npm-intellisense",
"christian-kohler.path-intellisense",
"cschlosser.doxdocgen",
"dbaeumer.vscode-eslint",
"eamodio.gitlens",
"esbenp.prettier-vscode",
"exiasr.hadolint",
"MichaelCurrin.auto-commit-msg",
"p42ai.refactor",
"Phu1237.vs-browser",
"redhat.vscode-yaml",
"spmeesseman.vscode-taskexplorer",
"streetsidesoftware.code-spell-checker",
"usernamehw.errorlens"
]
}
},
"forwardPorts": [
5901,
6080
],
"remoteUser": "vscode",
"runArgs": [
"--userns=keep-id:uid=1000,gid=1000"
],
"containerUser": "vscode",
"updateRemoteUserUID": true,
"containerEnv": {
"HOME": "/home/vscode"
}
}
host:
arch: amd64
buildahVersion: 1.30.0
cgroupControllers: []
cgroupManager: cgroupfs
cgroupVersion: v1
conmon:
package: conmon-2.1.7-2.fc37.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.1.7, commit: '
cpuUtilization:
idlePercent: 99.77
systemPercent: 0.08
userPercent: 0.16
cpus: 16
databaseBackend: boltdb
distribution:
distribution: fedora
variant: container
version: "37"
eventLogger: journald
hostname: ANT-MRDGH2821
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 524288
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 524288
size: 65536
kernel: 5.15.90.1-microsoft-standard-WSL2
linkmode: dynamic
logDriver: journald
memFree: 13533540352
memTotal: 16320323584
networkBackend: netavark
networkBackendInfo:
backend: ""
dns: {}
ociRuntime:
name: crun
package: crun-1.8.5-1.fc37.x86_64
path: /usr/bin/crun
version: |-
crun version 1.8.5
commit: b6f80f766c9a89eb7b1440c0a70ab287434b17ed
rundir: /run/user/1000/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
os: linux
pasta:
executable: ""
package: ""
version: ""
remoteSocket:
exists: true
path: /run/user/1000/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: false
serviceIsRemote: true
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.2.0-8.fc37.x86_64
version: |-
slirp4netns version 1.2.0
commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.3
swapFree: 4294967296
swapTotal: 4294967296
uptime: 0h 26m 49.00s
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
- ipvlan
volume:
- local
registries:
search:
- docker.io
store:
configFile: /home/user/.config/containers/storage.conf
containerStore:
number: 1
paused: 0
running: 0
stopped: 1
graphDriverName: overlay
graphOptions: {}
graphRoot: /home/user/.local/share/containers/storage
graphRootAllocated: 1081101176832
graphRootUsed: 2446757888
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "true"
Supports d_type: "true"
Using metacopy: "false"
imageCopyTmpDir: /var/tmp
imageStore:
number: 3
runRoot: /run/user/1000/containers
transientStore: false
volumePath: /home/user/.local/share/containers/storage/volumes
version:
APIVersion: 4.5.0
Built: 1681486976
BuiltTime: Fri Apr 14 21:12:56 2023
GitCommit: ""
GoVersion: go1.19.7
Os: linux
OsArch: linux/amd64
Version: 4.5.0 |
same here, refer this post #17313, but seems podman v4.6.1 still not fix this issue in windows |
To be clear on the specific issue for other users who stumble here from the internet: Dev Container features are not currently supported when using rootless Podman, on any OS whether it's Linux, Windows or macOS. If you remove the features from your I've duplicated this issue with my own error logs on the I'd love to get @rhatdan's take on this. Rootless Podman is used by default on the new Cloud Native distro, Project Bluefin, led by @bketelsen and @castrojo. It'd be great to have a single container engine implementation devs can use for all their development needs. |
@n1hility PTAL |
Thanks @rhatdan and @n1hility! To update, a devcontainer-with-features build works if you temporarily change the security context of SELinux on sudo chcon -R -t container_file_t /tmp/
devcontainer build --docker-path podman --workspace-folder ./
sudo restorecon -RFv /tmp/ My specific issue is also replicated in microsoft/vscode-remote-release#8557. So it would seem that some change between 0.275.1 and 0.282.0 of the ms-vscode-remote.remote-containers extension broke Podman with SELinux from building devcontainers with features. Tracking in devcontainers/features#755. @samruddhikhandale, who works at GitHub, very helpfully guided me to this workaround. |
@worldofgeese thanks for reporting back (btw great nick/handle!). I took a look at the issues, and I think we are just stuck waiting on the vscode team to fix this. If it was open source we could investigate a patch, but looks like the respective modules are proprietary. If there was a way to replace tmp with a common subdir (e.g. /tmp/devcontainers (might be possible with TMPDIR env) then you could set the selinux label permanently on that dir and not have to worry about it anymore. Other than that I think we just have to wait for them to specify a z mount flag. |
@worldofgeese Actually the devcontainers CLI RI is open which I think remote containers is just rebundling. Will take a look when I get a chance soon. Sorry for causing any confusion was looking for the source of remote release and hit their FAQ for “why not OSS?” |
All good and thank you for taking a look! I'll edit my comment in the other thread to remove my query around Dev Containers being proprietary. I'll also edit the quoted passage to reflect. |
So I took a look and the good news is that this would be a fairly simple fix on the devcontainers side (mount with z in two places, so things are properly relabeled). The bad news is that fixing this for selinux labeled volumes on Linux will break it on Mac/Windows since mounted host volumes don't support selinux context xattrs. We have talked about making non-supporting filesystems ignore relabeling (e.g. just warn/debug if we see EOPNOTSUPP [ see convo in /~https://github.com//issues/19852 and other related issues]). Since this is a frequent pain point I'll try to find some time (probably after the holiday) to propose a patch on this. // cc @rhatdan |
Agree about the pain point! |
I think it makes sense to just warn on ENOSUP |
@n1hility any news on this? a pain point for me on Mac. |
Issue Description
I have been trying to document how to set up Visual Studio Code and Dev Containers to use Podman instead of Docker. However, there are some issues that I have run into that are more difficult for me to figure out.
A basic setup for the Dev Containers seems to work fine for both Mac and Linux. However, veering away from the bare-bones examples proves to be unsuccessful.
Steps to reproduce the issue
Steps to reproduce the issue
podman
andpodman-compose
pathspodman
binary and add theDOCKER_HOST
environment variable to point to the podman socketdevcontainer.json
file:The Resulting
devcontainer.json
file:Describe the results you received
The container will fail to start with the following error in the logs:
Describe the results you expected
I expected the container to successfully start with no errors
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
Additional information
Additional incompatibilities:
devcontainer.json
file:devcontainer.json
file:This issue refers to the current open PR: #18679
The text was updated successfully, but these errors were encountered: