Bug 1847003 - podman 2.x seems to ignore workdir when running entrypoint
Summary: podman 2.x seems to ignore workdir when running entrypoint
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: podman
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Lokesh Mandvekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-15 12:03 UTC by Andreas Kohn
Modified: 2020-09-10 13:05 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-09-10 13:05:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Andreas Kohn 2020-06-15 12:03:25 UTC
Description of problem:

With a container build from this Dockerfile I have different behaviors between podman 1.9.3 and 2.0.0(-rc4.1, also tried -rc5 from koji):

```
FROM node:alpine

WORKDIR /app

RUN mkdir -p /app && echo '{"name":"test","scripts":{"start":"echo Ok!"}}' > /app/package.json

ENTRYPOINT [ "npm", "start", "--" ]

```

With podman version 2.0.0-rc4 (2:2.0.0-rc4.1.fc32):

```
$ docker run --rm -ti test
npm ERR! code ENOENT
npm ERR! syscall open
npm ERR! path /package.json
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, open '/package.json'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent 

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-06-15T12_01_38_623Z-debug.log
```

With podman version 1.9.3 (2:1.9.3-1.fc32):
```
$ docker run --rm -ti test

> test@ start /app
> echo Ok!

Ok!

```


Version-Release number of selected component (if applicable):

podman-plugins-2.0.0-rc4.1.fc32.x86_64.rpm                                                                              podman-2.0.0-rc4.1.fc32.x86_64.rpm

Comment 1 Andreas Kohn 2020-06-15 12:07:26 UTC
I see https://github.com/containers/libpod/issues/4429 (and related), but these focus on situations where the command is explicitly relative ("starts with ./"). In my case the command isn't, and "./npm ..." doesn't make sense. 

It seems more that podman/libpod? in general should run things inside the given workdir, after all that's why I specified that :)

Comment 2 Matthew Heon 2020-06-15 14:17:23 UTC
Can you provide more details here? Is `docker run` an alias to Podman (the `podman-docker` package perhaps)? Are you using the HTTP API, or directly executing Podman?

Comment 3 Andreas Kohn 2020-06-16 13:17:02 UTC
Yes, sorry about that: `docker` is indeed mapping to `podman` (as a shell function, because I read at https://askubuntu.com/a/98791/786783 that aliases seem to be a bit problematic).

I now tested some more combinations:

* rc5 / docker() { podman "$@" }: Fails with ENOENT as in the description
* rc5 / podman-docker rc5 package from koji: Fails with ENOENT as in the description
* rc6 / docker() { podman "$@" }: Works as expected (i.e. in the same way as podman 1.9.3 used to)
* rc6 / podman-docker rc6 package (from updates-testing): Works as expected (i.e. in the same way as podman 1.9.3 used to)

From my side therefore: This issue was fixed with the rc6 update. 

I'm not sure whether there should be somewhere a pointer to the podman-docker package, or maybe some super fancy magic to "suggest" to install it -- thanks for hint though!

Comment 4 Daniel Walsh 2020-06-16 17:49:36 UTC
Fixed in podman 2.0

Comment 5 Lokesh Mandvekar 2020-09-10 13:05:13 UTC
Closing, please reopen if issue isn't fixed.


Note You need to log in before you can comment on or make changes to this bug.