Add customizable unix permissions and ownership for Docker Volume Mounts

What problem will this feature address?

Some applications need a persistent data volume whose unix ownership is a non-root user, but the volume data starts out owned by root. This can happen when:

• The application uses a non-root user inside the container for all tasks, such as a user with the UID and GID set to 1000:1000, and
• The application needs any persistent data that the owner provides with a volume mount, which can be a bind, volume, or file mount.

For instance, I'm making a Ruby on Rails 7.2 application, and the production container creates a user with UID:GID 1000:1000. Because Docker volumes are owned by root (UID and GID 0:0, permissions set to 755), only root can write to the directory, and my application couldn't use the directory until I fixed the permissions myself (see below).

It would be convenient for the dokploy interface to help users to change permissions on volume mounts. This can be done manually over SSH, but the requirement would be surprising to users who do not expect permissions errors.

Describe the solution you'd like

Add a field to the Volume Mount creator, for all three kinds of mounts, to set the UID, GID, and file permissions (rwxrwxrwx) on the directory or file before mounting. For Volumes, the directory is /var/lib/docker/volumes/<name-of-volume>/_data (at least on my machine).

In lieu of this functionality, a warning could be added to the Volume Mount creator announcing that you must set the permissions yourself if your container application runs as a non-root user.

Describe alternatives you've considered

A user with root access can do this themselves in an SSH terminal. For example, for a container that needs the myvolume volume to be owned by the user and gid 1000:1000, they can:

ssh root@server
chown -R 1000:1000  /var/lib/docker/volumes/myvolume/_data

Additional context

No response

Start at the Volume Mount creator and trace how bind, volume, and file mounts are created. Review how Docker handles permissions for each mount type, then define acceptance criteria for configurable UID, GID, and rwxrwxrwx permissions or the alternative warning; done means the selected behavior is available consistently for all three mount kinds.