`WaitForMessageInLogs` uses `--tail=all` parameter which is not compatible with Podman's version of `docker` on Mac and returns
```
Error: invalid argument "all" for "--tail" flag: strconv.ParseInt: parsing "all": invalid syntax
```
as a workaround I used bash script
```
#!/bin/bash
# Docker wrapper for Podman compatibility
# Replaces --tail=all with --tail=-1
# Original command path
REAL_DOCKER="/usr/local/bin/docker"
fixed_args=()
for arg in "$@"; do
if [[ "$arg" == "--tail=all" ]]; then
fixed_args+=("--tail=-1")
else
fixed_args+=("$arg")
fi
done
exec "$REAL_DOCKER" "${fixed_args[@]}"
```
but more natural should be using `numLines = -1` parameter from [ClientStream.cs:16](https://github.com/mariotoffia/FluentDocker/blob/master/Ductus.FluentDocker/Commands/ClientStreams.cs#L16) in Podman's case
**Resolved in v3.0.0.** The v3 ground-up rewrite implements (or fixes) what this issue asked for.
The issue is a v2 bug: the old `WaitForMessageInLogs` fetched logs via `docker logs --tail=all`, and Podman's docker-compatible CLI on macOS rejects the literal "all" (it requires an integer), throwing `invalid argument "all" for "--tail" flag`. The reporter even links the offending v2 file `Ductus.FluentDocker/Commands/ClientStreams.cs:16`. In the v3 rewrite the entire `Ductus.FluentDocker` project (including ClientStreams.cs) was removed, and no v3 code emits the `--tail=all` literal anywhere. The v3 log-wait path passes `tail: null`, and every CLI driver emits a `--tail <int>` flag ONLY when an integer value is present (otherwise no flag at all), which Podman accepts. The reporter's own suggested fix (use an integer / -1 instead of "all") is effectively what v3 already does by simply omitting the flag when no tail count is requested.
<sub>Where this lives in v3: v2 buggy file removed: `Ductus.FluentDocker/` directory no longer exists in the repo (the issue references `Ductus.FluentDocker/Commands/ClientStreams.cs:16`). v3 wait-for-log path: `FluentDocker/Services/Extensions/ServiceExtensions.cs:256` `WaitForLogMessageAsync` calls `service.GetLogsAsync(false, ...)` (line 268), which in `FluentDocker/Services/Impl/ContainerService.Operations.cs:23` invokes `driver.GetLogsAsync(context, _containerId, follow, null, false, ...)` — the `tail` argument (4th positional, see interface `FluentDocker/Drivers/IContainerDriver.Operations.cs:42-48`, doc "null = all") is explicitly null. Podman CLI driver…</sub>
Closing as part of the v3 issue sweep. If your scenario still isn't covered by v3, please reopen with a v3 reproduction and we'll take another look. Thanks for the report! 🙏