Apache Airflow version
3.1.0
If "Other Airflow 2/3 version" selected, which one?
No response
What happened?
The @task.kubernetes decorator fails when used with non-root container images such as the official apache/airflow image.
After PR #28942, the initialization phase for Kubernetes-decorated tasks creates the directory /airflow/xcom (see providers/cncf/kubernetes/decorators/kubernetes.py#L98).
However, in the default Airflow image the container runs as the airflow user, (see HERE) which does not have write permissions to /. As a result, the attempt to create /airflow/xcom fails with a permissions error, and the Kubernetes task cannot start.
{"timestamp":"2025-10-10T13:10:06.622360Z","level":"info","event":"[base] + mkdir -p /airflow/xcom","logger":"airflow.providers.cncf.kubernetes.utils.pod_manager.PodManager","filename":"supervisor.py","lineno":1739}
{"timestamp":"2025-10-10T13:10:06.622493Z","level":"info","event":"[base] mkdir: cannot create directory ‘/airflow’: Permission denied\n"
What you think should happen instead?
The Kubernetes-decorated task should run successfully, even when the image runs as a non-root user.
How to reproduce
-
Use the official Apache Airflow 3 image, e.g.:
image: apache/airflow:3.1.0
-
Define a DAG:
from airflow.decorators import dag, task
from datetime import datetime
@dag(start_date=datetime(2024, 1, 1), schedule=None)
def test_dag():
@task.kubernetes(image="apache/airflow:3.1.0")
def example_task():
print("Hello from Airflow task")
example_task()
test_dag()
-
Trigger the DAG.
Operating System
Kubernetes (Airflow charts)
Versions of Apache Airflow Providers
Latest
Deployment
Official Apache Airflow Helm Chart
Deployment details
Airflow version: 3.1.0
Executor: @task.kubernetes)
Base image: apache/airflow:3.1.0
Kubernetes version: (v1.32)
Anything else?
The /airflow/xcom directory is currently created unconditionally during initialization, assuming root permissions.
Possible approaches to resolve this:
- Create the directory under a writable path such as /tmp/airflow/xcom, or
- Make the XCom path configurable for Kubernetes-decorated tasks, or
- Check for existence and create the directory only if it’s writable by the current user.
Are you willing to submit PR?
Code of Conduct
Apache Airflow version
3.1.0
If "Other Airflow 2/3 version" selected, which one?
No response
What happened?
The
@task.kubernetesdecorator fails when used with non-root container images such as the officialapache/airflowimage.After PR #28942, the initialization phase for Kubernetes-decorated tasks creates the directory
/airflow/xcom(see providers/cncf/kubernetes/decorators/kubernetes.py#L98).However, in the default Airflow image the container runs as the
airflowuser, (see HERE) which does not have write permissions to/. As a result, the attempt to create/airflow/xcomfails with a permissions error, and the Kubernetes task cannot start.What you think should happen instead?
The Kubernetes-decorated task should run successfully, even when the image runs as a non-root user.
How to reproduce
Use the official Apache Airflow 3 image, e.g.:
Define a DAG:
Trigger the DAG.
Operating System
Kubernetes (Airflow charts)
Versions of Apache Airflow Providers
Latest
Deployment
Official Apache Airflow Helm Chart
Deployment details
Airflow version: 3.1.0
Executor: @task.kubernetes)
Base image: apache/airflow:3.1.0
Kubernetes version: (v1.32)
Anything else?
The /airflow/xcom directory is currently created unconditionally during initialization, assuming root permissions.
Possible approaches to resolve this:
Are you willing to submit PR?
Code of Conduct