[Question] [Tenant Creation] Not automatically creating new tenant locally

[aaryan-purohit]

Search before asking

• [X] I had searched in the issues and found no similar issues.

What happened

I am running the workflow engine as standalone server. Whenever I create a new tenant which is not present locally as a user in my machine, the workflow is failing. I have referred the doc: https://dolphinscheduler.apache.org/en-us/docs/3.2.1/guide/security/security, and replicated the same steps mentioned here to automate the creation of tenant. But it's not working.

What you expected to happen

It will create a new tenant automatically, and workflow will run successfully.

How to reproduce

Copy the commands - worker.tenant.auto.create = true; worker.tenant.auto.create = truesudo in worker.properties common file as mentioned in the documentation. Create a new tenant which is not created in your local machine, through the UI. Run any simple workflow (even print statement), it will not create the new tenant automatically and the workflow will fail.

Anything else

Here are the logs screenshot:

Version

dev

Are you willing to submit PR?

• [ ] Yes I am willing to submit a PR!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[SbloodyS]

The main reason is Permission denied.

[aaryan-purohit]

Can you tell how to fix that?

[aaryan-purohit]

Hey, can you guide on the permission issues here?

[yelijing18]

您好 @SbloodyS ，我在 Kubernetes 中部署的 DolphinScheduler 3.2.1 实例也遇到了同样的问题。 Hello, I also encountered the same issue with my DolphinScheduler 3.2.1 instance deployed in Kubernetes.

我使用默认的 Chart values.yaml 文件进行部署，因此 worker.tenant-auto-create 配置是打开的，且默认的租户为 'default'。 I used the Chart's default values.yaml file for deployment, so the worker.tenant-auto-create configuration is enabled, and the default tenant is 'default'.

在日志中可以观察到，任务实例执行过程中确实执行了 useradd -g root default 命令创建了用户，但在 Worker 的 Pod Shell 中可以观察到 /home 下没有 default 目录。 In the logs, it can be observed that during the task instance execution, the useradd -g root default command was indeed executed to create the user, but in the Worker Pod Shell, the default directory is not present under /home.

这导致后续的 sudo -u default -i ... 命令执行时输出了错误信息，因为 /home/default 不存在，但这不影响任务执行。 This causes the subsequent 'sudo -u default -i ...' command to output an error because /home/default does not exist, but it does not affect task execution.

在我的工作流定义中，我尝试向当前目录写入文件，但提示 Permission denied。 In my workflow definition, I tried to write files to the current directory but received a "Permission denied" message.

此时的工作目录理论上是 /tmp/dolphinscheduler/exec/process/default/14472852420160/14472904679872_2/8/8/。 The working directory at this time is theoretically /tmp/dolphinscheduler/exec/process/default/14472852420160/14472904679872_2/8/8/.

在 Worker 的 Pod Shell 中可以观察到，从 /tmp/dolphinscheduler/exec 目录开始，其权限就已经是 755 且拥有者并非租户对应的用户。 In the Worker Pod Shell, it can be observed that from the /tmp/dolphinscheduler/exec directory onwards, the permissions are 755 and the owner is not the user corresponding to the tenant.

以下是完整的日志文件： Here is the log file: task-log.log

这里存在两个问题： There are two issues here:

1. 虽然用户新建成功，但并未为其在 /home 下创建家目录（不影响任务执行）。

2. Although the user is created successfully, a home directory is not created under /home (this does not affect task execution).

3. 虽然 /tmp/dolphinscheduler 目录的权限是 777，但其用租户名称命名的子目录 /tmp/dolphinscheduler/exec/process/default 的权限是 755 且拥有者为 root ，导致租户对应用户无法在其目录下创建文件（影响任务执行）。

4. Although the permissions of the /tmp/dolphinscheduler directory are 777, the subdirectory /tmp/dolphinscheduler/exec/process/default named after the tenant has permissions of 755 and is owned by root, which prevents the tenant user from creating files in this directory (affecting task execution).

因此这确实可能是一些 Bug，请协助定位和解决。 Therefore, this could indeed be a bug. Please assist in identifying and resolving it.

[yelijing18]

15670 已经修复了 home dir 的问题，但未找到 /tmp/dolphinscheduler 权限的相关内容

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity for 30 days. It will be closed in next 7 days if no further activity occurs.