shares:
  - directories: "/musique"

is working fine. Thanks

On 12/11/2023 at 2:13 PM, VelcroBP said:

I'm not finding any info in either documentation regarding an existing configuration option for permissions or how to add them to the template. I'm probably overlooking it. 

 

Did you have any luck getting permissions working?

 

I tried adding --user 99:100 as a post argument, and it's still not working.

 

I have to reset permissions on my downloads folder before other containers can interract with the files.

 

It makes sharing/contributing next to impossible, as well.

Edited March 26, 20242 yr by nmkaufman

59 minutes ago, nmkaufman said:

 

Did you have any luck getting permissions working?

 

I tried adding --user 99:100 as a post argument, and it's still not working.

 

I have to reset permissions on my downloads folder before other containers can interract with the files.

 

It makes sharing/contributing next to impossible, as well.

Hi,
I'd like to emphasize that I'm not the image author but only created the template.
This means I generally can't help with any modifications that do not exist in my default template that I provide.

That being said, I think you have multiple options to fix the container permissions:

• Ensure that the directories are owned by the docker user. This is usually "nobody". You can also add this user to a group on your host machine and permit write & read to this user. The application shouldn't need execute.
• It seems that the container runs on root via default: https://github.com/slskd/slskd/blob/master/docs/docker.md . You could ensure that root can write & read on these directories.
• In the worst case, you could permit all users to write & read. This is considered bad practice and is not recommended. However, it might not be too bad if no parts of your server are exposed.

If you still have trouble, I would suggest reaching out to the author of slskd. Keep in mind that they usually don't know "Unraid" or other distributions and they expect you to provide the docker run command (you can obtain this from Unraid). I hope this helps.

18 hours ago, manrw said:

Hi,
I'd like to emphasize that I'm not the image author but only created the template.
This means I generally can't help with any modifications that do not exist in my default template that I provide.

That being said, I think you have multiple options to fix the container permissions:

• Ensure that the directories are owned by the docker user. This is usually "nobody". You can also add this user to a group on your host machine and permit write & read to this user. The application shouldn't need execute.
• It seems that the container runs on root via default: https://github.com/slskd/slskd/blob/master/docs/docker.md . You could ensure that root can write & read on these directories.
• In the worst case, you could permit all users to write & read. This is considered bad practice and is not recommended. However, it might not be too bad if no parts of your server are exposed.

If you still have trouble, I would suggest reaching out to the author of slskd. Keep in mind that they usually don't know "Unraid" or other distributions and they expect you to provide the docker run command (you can obtain this from Unraid). I hope this helps.

 

I will play around with it, this weekend.

 

I believe the problem is that it's creating files, owned by ROOT, while other containers use NOBODY, by default.

 

It's not setting permissions that allow other users to access the files.

 

The easiest solution would be to set the UMASK, but I tried passing a UMASK environmental variable to the container, and it didn't seem to work. I did see a reddit thread where someone claimed this worked, though, so I'm going to further experiment.

Edited March 27, 20242 yr by nmkaufman

17 minutes ago, nmkaufman said:

 

I will play around with it, this weekend.

 

I believe the problem is that it's creating files, owned by ROOT, while other containers use NOBODY, by default.

 

It's not setting permissions that allow other users to access the files.

 

The easiest solution would be to set the UMASK, but I tried passing a UMASK environmental variable to the container, and it didn't seem to work. I did see a reddit thread where someone claimed this worked, though, so I'm going to further experiment.

Sounds good 👍.

If you still have any trouble after that I would suggest that you open an slskd issue.

On 3/17/2024 at 6:21 AM, Maitresinh said:

 shares:
  - directories: "/musique"

is working fine. Thanks

 

That's all you put in your config.yml and it works???  I've been messing with this for days and still get the error:

 

Failed to scan share /Media/Music: Could not find a part of the path '/Media/Music'

 

I've tried it all the way from /mnt/user/Media/Music and still get the same error no matter what configuration I use.  Your full path is /musique and that's all???  You didnt' add some PATH to the original docker container or anything like that?  Just edited the YML?

Edited April 9, 20242 yr by CoZ

On 3/2/2024 at 5:06 PM, manrw said:

Please note that you must mount your directories to inside the container using a path mode (prefer read-only if possible). Then reference this path using the config.

 

This might be my issue.  Why does the docker container template not have those PATHs "built into" the template?  Should the template not have a blank entry for Downloads and Incomplete and Music folder that the user than fills in like other docker templates???

Hi,

 

I'm trying to install homarr and get this error:

 

 

 

Is this a known issue? Any help?

 

Thanks

 

 

18 hours ago, Pusheru said:

Hi,

 

I'm trying to install homarr and get this error:

 

 

 

Is this a known issue? Any help?

 

Thanks

 

 

Hi, this is not an issue with the template:

https://forums.unraid.net/topic/141336-cant-pull-or-update-docker-containers-dns-issue/

there a way to mount a drive on dashdot ? i don't have any idea to mount the drives

Dashdot should not need any persistence on the file system. The default set-up should work. Can you explain why you want to mount?

If you want to mount the container, you can do this by editing the container.

On 5/4/2024 at 5:51 PM, manrw said:

Dashdot should not need any persistence on the file system. The default set-up should work. Can you explain why you want to mount?

If you want to mount the container, you can do this by editing the container.

 on first run, it show no mount found but other can have drive stats. i try find any source how to mount a drive and there no documentation to add the stogare, and yesterday found other had same issue with me https://github.com/MauriceNino/dashdot/issues/1046

Edited May 5, 20242 yr by Ellissss

On 3/27/2024 at 10:10 AM, nmkaufman said:

 

I will play around with it, this weekend.

 

I believe the problem is that it's creating files, owned by ROOT, while other containers use NOBODY, by default.

 

It's not setting permissions that allow other users to access the files.

 

The easiest solution would be to set the UMASK, but I tried passing a UMASK environmental variable to the container, and it didn't seem to work. I did see a reddit thread where someone claimed this worked, though, so I'm going to further experiment.

Did you ever figured this out?  Having the same issue when it comes to Lidarr.

I found this note on the GitHub:

 

https://github.com/slskd/slskd/issues/49#issuecomment-1094113810

Looks like he's getting ready to solve the issue further.  Once we can set the files to 777 we should be good, right?

 

https://github.com/slskd/slskd/compare/79cd6c0033631b33e9508b7c10e48b9edfafe21d...4f50d184c8923d975e5930a66a6385683823ef77

6 hours ago, EC28 said:

Looks like he's getting ready to solve the issue further.  Once we can set the files to 777 we should be good, right?

 

https://github.com/slskd/slskd/compare/79cd6c0033631b33e9508b7c10e48b9edfafe21d...4f50d184c8923d975e5930a66a6385683823ef77

Hi, you can add the user flag in the "Extra argugments" when editing the docker container.
You may need to activate the advanced mode if you do not see this field.
Please do not ask the image authors for Unraid specific questions, because they usually will not know how Unraid works.

Setting 777 will work but is strongly not recommended, because it will enable anyone on the machine to write, read, delete and execute these specific files. This is considered to be dangerous because this could be used in a malicious way and is therefore considered bad practice.

How would I format the user flag in the field?  Currently I have the routing through the bittorrent container for VPN use.

1 minute ago, EC28 said:

How would I format the user flag in the field?  Currently I have the routing through the bittorrent container for VPN use.

Just ensure to put a space between options like you do on Linux commands:

 

--optionA valueA --optionB valueB

In your case, that would probably be something along the lines of --network mycontainer --user ???:???

Thanks!

 

So it would need to be --user nobody:users

Getting this error when I add the user flag.  If I take the tag back out, it functions fine.

 

Just got the bot up and running but nothing is working? The bot has access to the music library but I'm getting the below error

 

[Nest] 28  - 10/10/2024, 4:02:14 PM   ERROR [JellyfinSearchService] Failed to search on Jellyfin: Error: SearchHints were undefined

 

I think I found the issue?  Line 160 in src/commands/play/play.command.ts

 

 

const hints = await this.jellyfinSearchService.searchItem(

 

I think it should now be "this.jellyfinSearchService.SearchTerm("

 

Hi @strykar_wolf, please report the issue to the GitHub repository. Thank you

OK. I've done so, I'm not sure much on what the issue is but I hope I pointed you in the right direction!

@EC28 You may have figured it out or given up, but I just went through this. Figured I'd post in case anyone comes across it.

 

You have to add "--user 99:100" into extra parameters, but you also have to chown your appdata folder. So, in my case, I had to run "chown -R 99:100 /mnt/user/appdata/slskd" 

 

Then restart the container.