Repository navigation
Clearly error when ownership check fails when walking parent directories to find a Taskfile #1683
Description
I ran into a tricky issue where Task wasn't finding an expected Taskfile: https://github.com/orgs/ddev/discussions/6273
What was confusing to me is that https://taskfile.dev/next/usage/#running-a-taskfile-from-a-subdirectory says
it will walk up the file tree until it finds one (similar to how git works)
I think it's common for this to refer to git not crossing mounted file systems when looking for a .git directory. It wasn't clear to me that this would also involve ownership checks, which is done here:
Lines 148 to 150 in 40d7715
I assume this is all to prevent potential security issues like the one in Git https://github.blog/2022-04-12-git-security-vulnerability-announced/.
It'd be great if Task could either:
- Clearly say why it stopped walking parent directories.
- Or, if we don't need to check ownership then don't.
Activity
NikitaCOEUR commentedon Jul 17, 2024
Same problem on my side, an issue in a GITHUB ACTION CI running in a container.
I am working in a child directory of the GitHub repository, and the owner is different between :
Also, if no Taskfile is found by going up from the child directories to the root of the repository, no Taskfile is found at the root either since the owner has changed...
Only workaround: execute the task by targeting the Taskfile directly:
solidDoWant commentedon Oct 31, 2024
I ran into this as well, using vscode dev containers on Windows. Repo gets mounted to
/workspaces/<dir name>. This directory is owned by root, with perms set to0o777. All files within the directory are owned by thevscodeuser. As a result, I cannot runtaskfrom any subdirectory.It'd really be great if either the check was removed, or there was a global option (env var preferably) to disable it.
trulede commentedon Dec 10, 2025
Did either of you ever make progress, or learn some new details when running in docker?
I personally run Task in container environments (specifically devcontainers) and its fine. But the user-id issue and mounts can be tricky. Its possible the check (on user-id) exists because Task does create temporary files and this might fail in some cases. (but not all).
If we can pin downs some more detail, it could be an idea to add an environment variable to manage that. Similar to the existing
TASK_TEMP_DIRenvar.solidDoWant commentedon Dec 11, 2025
I did not. I ran into enough issues with taskfiles that I just stopped using it entirely. No one single issue - it was death by a thousand cuts.
deviantintegral commentedon Dec 11, 2025
This was very much an edge case for us, and hasn’t come up since. The worst was how it was silent behaviour - I think a log message, even if it was only in verbose mode would meet our needs.
trulede commentedon Feb 7, 2026
The code has changed quite a bit, its not trivial to implement this ... but it looks OK.