`/data` directory belongs to `root:root`

[Dennis So]

if [ "${CHECK_PERM_DATA}" = true ]; then
  f_log INF "Apply data permissions... "
  find /data ! -user "${UID}" -exec chown -h "${UID}:${GID}" {} \;
  chown root:root /data # fix chroot sftp
  f_log SUC "done" # success of Apply data permissions
fi

startup#L176-L181

Because the /data volume is mounted to the host machine’s filesystem, the directory will be owned by the root user now. Why is the /data directory owned by the root user? Shouldn't this directory be owned by the supplied UID and GID instead?

Thanks for maintain this image by the way.

[Dennis So]

Looks like by setting CHECK_PERM_DATA to false, will prevent the root user taking ownership the /data directory.

chown root:root /data # fix chroot sftp

Why does sftp require us to set this directory to belong to root?

[Alexandre Levionnais]

The chroot folder /data must be owned by root to work. Indeed it's specific to my use.

But what is your problem with this, maybe we can find a more elegant solution.

[Dennis So]

I'm currently mounting a non-root directory into this directory because I didn't want to run this container under root. Since we are passing in UID and GID as the environment variables, I didn't expect the folder would be owned by root.

The workaround of setting CHECK_PERM_DATA to false works fine for me. A more elegant solution can be CHECK_PERM_DATA should use the UID and GID to own the directories instead of root. Another solution can be defaulting CHECK_PERM_DATA to false.

I'm not sure how does your workflow works. Shouldn't root already have access to all files within the system?

[Alexandre Levionnais]

Ok, I found another solution. I have removed the line chown root:root /data