Can you not provide the root directory ‘/‘ and let user pick from all included options?
Most other programs include a “standard” option like /music but then allow a user to move up the folder system and select another folder
Docker compose - any examples?
Ok perhaps I can do that so it always starts from /, and then everything mounted will be shown under that. But it also means the whole container filesystem will also be exposed, I’m not sure if that’s a good thing.
I will have to try it.
Most other media type applications I use in docker do exactly this. When I go to add a path for a folder it starts at / and shows me everything. People using docker are savvy generally enough to know what their maps are so I would go immediately to /data for my folders.
Cheers!
Hi, new user here evaluating using this in docker also. It would appear this issue has not been addressed yet. When I click on the issue, I am not able to see any activity so was curious about the status.
I would like to be able to map multiple volumes as paths from the root into the container from which I can select to different directories to scan. And I agree with @Pprior that this is widely supported for similar use case in docker containers.
I understand the concern you raised about exposing the entire container root as selectable, but could you not just hide the known system and config related directories and just display what is left in the root? Current docker users who are just mapping to /music won’t notice a difference, but it will allow others to add multiple volumes or specify their preferred path tp support the concern raised by @Pprior.
Plan to do it but not done yet. But in meantime if you just map / to /music then everything will be visible to SongKong i think?
Mapping your host’s root into a docker container is not a recommended practice for sure.
The work around that I came up with was to map into
/music/host_source_1
/music/host_source_2
Okay so how does that differ from the ideal scenario for you?
I think it comes down to the original issue raised when I go to rename files which will effectively move them across the mapped sources. I need to purchase your license to test that of course.
I am still playing some with the preview, but I am impressed and pretty sure I will purchase the license as I see the value here. It is a nice solution.
It would be great if you are able to implement exposing the container root to select a directory. Given you are only exposing directory structure, I am not sure there is an issue with exposing system and config directories, but you could always hidoe those in the UI since those are known to you.
Thanks for the consideration.
Well you can do that , just map / to /music
I understand from your previous comments that your experience with Docker is limited, but that is a bad practice. And sorry to sound harsh, but very poor advice to providing as support on your forum when some of your users are likely unfamiliar with the security risks of this suggestion.
Volume mounts are a direct hook into the system. if you mount / into the container, you are giving anything running into the container unrestricted access to modify or delete system files on the host. That is a complete system compromise and not a good practice. I am not suggesting you would purposely compromise my system, but surely you know how these things can happen by accident. The whole point of Docker with bridge networking is to isolate the application in a “sandbox.”
Hi, yes I know it is bad practice but it sounded like that is what you wanted to do when you said it would be great to implement exposing the container root.
Sorry I don’t understand what you actually want?
I was talking about exposing the root inside the container in your web UI where you select a folder.
I am sorry I was not clear enough. Let me try again.
Docker allows me to mount volumes anywhere in the container. So for example, I could mount volumes to
/music
/data
/storage
Most similar containerized applications similar to songkong like Plex, Lyrion, etc. support selecting any of those directories available inside the container to specify your data or library. However Songkong’s web UI is currently limited to only expose /music and I would like to see the other volume mount points without having to place them in /music if possible. That is what I was asking. I thought you understood that as that was the last discussion point in the original request from @Pprior, but admittedly this was an old thread. Sorry about that.
My request was to expose in your web UI where you select a folder, the / inside the container so a user can select from /music or any other /path that is available in the container. If you wish to keep things tidy, you could hide all of the system and config related directories that are known and should not be selected anyways (but most of the others do not bother doing so). This would leave the selector show just /music and any other root directories that a user chose to mount in the docker container. I believe this change would address the original question raised which you captured as an issue here:
https://jthink.atlassian.net/browse/SONGKONG-2543
Ok I get it, so currently the code expects to find something mounted under /music, instead it should display whatever has been mounted from the dockers root /. So user could map a folder to /music or to any other path.
There continues to be confusion about docker practices. As a developer supporting potential homelab users I think it would definitely benefit you to explore this a little more as many of us are exactly the kind of people who would use a product like yours. In my case I’ve currently moved to a different solution even though I’ve already purchased a license.
Docker containers do not reason from the host’s real path structure. They reason only from the internal mount paths presented to them. So example: /mnt/tank/data/music is the real folder on Ubuntu, mapping it as /music in one container and /data/music in another destroys path consistency across the stack. That inconsistency makes cross-container interoperability, path translation, troubleshooting, and filesystem-aware operations more fragile. Best practice is to map a common parent consistently in all related containers, such as /mnt/tank/data to /data , so every app sees the same directory tree.
By forcing internally the only option to be /music that breaks our flexibilty and is not best practice. We are NOT asking you to expose root folder. What the ask is a simple variable that could default to /music within the progam but be able to be changed. I see no operational reason why you would want to force every single program user to put their files in a folder called /music.
It’s very unlikely that any docker user is going to be mapping folders as root (/). You continue to miss the idea on that one.
Yes, any path inside the container.
@Pprior did a better job of explaining why. It is best to keep all the internal mount points across your containers the same.
It is good to still provide users a recommended mount point in your example Docker run statement and compose file. I would suggest you will get more adoption with a published example Docker compose file also. This will open you up to novice users on many platforms.
Hi, thanks I get it (or at least think I do). Currently SongKong builds the folder tree data starting at /music I should change it to build from / instead. I realize this isn’t the actual / but it just means that anything mounted to any virtual folder such as /data will now be accessible within SongKong
So would be no new special variable required just instructions that your music folder(s)/volumes(s) need to be mounted in order for SongKong to be able to process them. But would no longer have to be mounted to /music mount point, could now be mounted to anything you like.
Correct?
I will try and get this done soon
That is correct.
The container is a virtual Linux environment based on the base linux image specified in your dockerfile. So / is the root directory in the virtual linux environment running inside the container.
The user needs to map a persistent storage location for the /songkong VOLUME you have defined in the dockerfile otherwise they will lose their prefs, database, logs and reports when the container shuts down.
Once you support selecting from the container / for your music, then a user can either mount their library to your recommended /music VOLUME or specify their own mount point like /data inside the container in their compose file (or docker run statement). A volume for /music will still always be created on the host when the container runs because you have that defined as a VOLUME in the dockerfile, but if the user has not mapped a persistent storage location, it will disappear when the container shuts down. A user can define as many volumes as they wish for the container in their compose file (or run statement) both with and without a persistent host storage mapping. Those without a persistent host storage mapping will disappear when the container shuts down.
Hi, I have fixed this in this release so now SongKong looks from the virtual / mount point, please give it a go.