Both sides previous revision Previous revision Next revision | Previous revision |
omv7:docker_in_omv [2024/11/10 10:34] – [User and permission management in docker and OMV. More security.] chente | omv7:docker_in_omv [2025/01/09 15:53] (current) – [2. Plugin Settings] chente |
---|
Done. We now have a user //jellyfin// with a primary group //jellyfin// that we can assign to the jellyfin container and we can guarantee that it will only have access to the folders we give it permission to. The //jellyfin// user will not be able to access any other folder on the system since it does not belong to the //users// group. Additionally, the persistent data in the jellyfin container will belong to the //jellyfin// user and the //jellyfin// group, so no other container will be able to access those files either. If we want another user to have access to that persistent data we just have to include it in the //jellyfin// group. Now we have that container perfectly isolated. | Done. We now have a user //jellyfin// with a primary group //jellyfin// that we can assign to the jellyfin container and we can guarantee that it will only have access to the folders we give it permission to. The //jellyfin// user will not be able to access any other folder on the system since it does not belong to the //users// group. Additionally, the persistent data in the jellyfin container will belong to the //jellyfin// user and the //jellyfin// group, so no other container will be able to access those files either. If we want another user to have access to that persistent data we just have to include it in the //jellyfin// group. Now we have that container perfectly isolated. |
| |
**In this document we will use a single user called //appuser// and created in the GUI, this is enough for 99% of users. Consider your use case and whether or not you need to go further, if you do act accordingly throughout the process.** | **In this document we will use a single user called //appuser// and created in the GUI, this is more than enough for 99% of users. Consider your use case and whether or not you need to go further. If you do, act accordingly throughout the entire process.** |
| |
---- | ---- |
</span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> |
If you don't have a fast drive for Docker, you can configure the <i>data</i> and <i>appdata</i> folders in the same shared folder. This will make the CHANGE_TO_COMPOSE_DATA_PATH variable serve to define the path of both. This is how the plugin example files are preconfigured. | If you don't have a fast drive for Docker, you can configure the <i>data</i> and <i>appdata</i> folders in the same shared folder. This will make the CHANGE_TO_COMPOSE_DATA_PATH variable serve to define the path of both. This is how the plugin example files are preconfigured. |
| </tr></table></body></html> |
| * ...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">  Beginners Info |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> |
| The internal structure described in the "data" folder is unimportant. In this document, a "standard" structure has simply been described for illustrative purposes, so that the reader has a general idea about what the content of that folder may be. You can distribute within that folder any directory tree that you feel comfortable with. |
</tr></table></body></html> | </tr></table></body></html> |
* CONFIGURE THE DATA FOLDER: | * CONFIGURE THE DATA FOLDER: |