xthursdayx

Okay, great. Thanks for your help. I wonder what caused that to change in the first place...

Sorry, what should I be looking for in there? This is what mine looks like now: root:x:0:0::/mnt:/bin/bash bin:x:1:1:bin:/bin:/bin/false daemon:x:2:2:daemon:/sbin:/bin/false adm:x:3:4:adm:/var/log:/bin/false lp:x:4:7:lp:/var/spool/lpd:/bin/false mail:x:8:12:mail:/:/bin/false news:x:9:13:news:/usr/lib/news:/bin/false uucp:x:10:14:uucp:/var/spool/uucppublic:/bin/false ftp:x:14:50::/home/ftp:/bin/false smmsp:x:25:25:smmsp:/var/spool/clientmqueue:/bin/false mysql:x:27:27:MySQL:/var/lib/mysql:/bin/false rpc:x:32:32:RPC portmap user:/:/bin/false sshd:x:33:33:sshd:/:/bin/false gdm:x:42:42:GDM:/var/state/gdm:/bin/false avahi:x:61:214:Avahi Daemon User:/dev/null:/bin/false avahi-autoipd:x:62:62:Avahi AutoIP Daemon User:/dev/null:/bin/false messagebus:x:81:81::/dev/null:/bin/false pop:x:90:90:POP:/:/bin/false nobody:x:99:100:nobody:/:/bin/false ntp:x:44:44:User for NTP:/:/bin/false tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/:/bin/false

Yeah, the only other way around this, if you have a motherboard and soundcard that supports it, is to setup a VM with the soundcard forwarded to it, connect your stereo to your soundcard output, install Roon Core in the VM and then play driect. It's not a very clean option though, imo. I think using a separate endpoint is the way to go. You can build one fairly inexpensively with a RPi and a Hifiberry DAC or Digi (SPDIF out).

Yeah, that's what it seems like, but I don't even remember an option to change the directories when installing the plugins...

To be honest, I ran into a lot of random DNS and network connectivity issues when I was trying out running Pi Hole on UNRAID, so who knows. I now run a separate pfSense machine as a firewall and router and have never looked back 😁 It shouldn't matter at all, but one thing you could try, if you're interested in troubleshooting, is to map the ports RoonServer users rather than using the `--net=host` setting. That way at least you could tell your router specifically which ports Roon traffic will be on (if that matters in your network environment). You won't be able to change the ports because Roon clients don't have the option to use different port connections, but it still might be interesting. I am going to try it out just to see if it works, so I just forked steefdebruijn's image and changed up the Dockerfile to expose the ports Roon uses for discovering and connecting/transferring data (9003/udp for discovery and 9100-9200/tcp for connection and playback), I'll build it and throw it up on Docker Hub just to try it out for myself. If you think that mapping the ports would be of any use in diagnosing your connection problems and want to try it but aren't sure how to pull the alternative version and change your UNRAID Roon docker template just ask and I can tell you how. EDIT: So you know, it works, but it's pretty impractical to do since you have make sure that none of the ports between 9100 and 9200 are already mapped.

I don't know anything about the ronch Roon docker image, but I do know that Roon is designed to be backed up and restored, so as long as you've made a recent backup you should be able to restore it in your new CORE without any issues. From what I understand, it doesn't really matter what platform you run Roon Server or Core on - Docker, VM, Windows laptop, etc - the backups are not platform dependent, they're just dependent on the Roon Server software. A VM just to run Roon seems like a bit of an overkill to me, but I haven't had any issues with connectivity or anything (so far at least), so I can't really speak to whether a VM would be more stable in your network.

Hi folks, just wanted to report something strange that I believe was linked to this plugin: A while ago I started noticing unexpected directories appear in the /mnt directory on my server, specifically directories called /.config and /.local. These have never existed before and I haven't recently added any new plugins to my server that would have created them. I also checked all of my docker container mappings and none are linked to these directories. I then tried deleting them but they kept reappeared. Upon further inspection .cache and .config seem to be related to Midnight Commander as they both a directory called mc in them. In the .local directory I found the following structure: /.local/share/mc/mcedit. However, in the /.freeipmi directory there was a subdirectory called sdr-cache with a file in it called sdr-cache-<my-server-name>.localhost. This file was difficult to read because it was not in UTF encoding, however I was able to make out lines that looked like the IPMI plugin out put. Because of this I tried deleting the IPMI plugin and have found that none of these unexpected directories have been recreated. Any idea why that could have been happening?

Exactly, I just made a template for other folks since people seem to stumble over creating their own volume mappings. No need to dump your existing config as it's probably the same as the template (minus the container icon).

Hey folks, just to let you know, I've made an UNRAID template for this RoonServer docker that should be showing up in Community Applications now (since I have a linked template repo). Thanks for your work getting this working @dkerlee. Cheers and feel free to let me know if you have any problems here:

Finally got around to sorting this out. Password reset now works. Please pull the new version of the container and let me know if you run into any issues. Cheers.

That's odd, I just pulled a new container and tried to create an account via the Mac app without any trouble. I do know that there is an current issue with Ferdi and importing existing Franz credentials that came about due to changes in Franz's code base (see issue here). This seems like it might be an upstream issue, so would mind creating an issue here: https://github.com/getferdi/server/issues so that we can work on it at the ferdi-server level, rather than at the docker container level?

Hmmm, that's strange. I wish I could help you understand what's going on, but I'm not really sure to be honest. If your network is set to allow traffic from 192.168.1.23 (I assume you meant that, not 192.168.23) to 192.168.1.10 and you set up your database correctly, I don't know any reason why it wouldn't be working and I don't think anyone else has run into this problem so it's hard for me to troubleshoot it... Are you able to connect to your database directly via any other machine on your network?

Thanks for helping to sort this out @joroga22! I can update my template to reflect the config directory versus the actual turnserver.conf file, however in the Readme.md for the original docker container Instrumentisto suggests that you have to specify the actual config file when running the docker, which is why I set it up like I did. However, if you're finding that this is working for you then that's great! It might be the case that you need to specify the turnserver.conf the first time you create the container (to prevent the Dockerfile from generating one internally within the docker container's filesystem), but then can swap it back to the directory after that. I'm not sure to be honest. Glad it's work for you though!

I'm finding an issue with locale encoding. I need to add a huge number of files to my nextcloud instance, so I added them manually to my user's "files" directory on my server and then ran `sudo -u abc php7 /config/www/nextcloud/occ files:scan [user]` from with the nextcloud container. However, I'm now getting some error messages like this: Entry "/xthursdayx/files/Work/Documents/Privado - Unknown - Boletín de políticas.pdf" will not be accessible due to incompatible encoding Entry "/xthursdayx/files/Archive/2019-2020/Materials/Jönsson - 2010__xid-389489066_2.pdf.xml" will not be accessible due to incompatible encoding Any idea how I might fix this? I assume that it is an issue with the container not using the correct UTF locale, but I could be totally off base...

Just to update, I was able to fix things by updating via terminal. Not sure what caused the original issue, but glad that it's sorted out now. Cheers.

I just had this exact same problem while updating to 19.02 from the most recent version of Nextcloud 18 (see error message below). I can no longer access the WebUI. I guess I will try updating via terminal if no one else has any suggestions. Internal Server Error The server was unable to complete your request. If this happens again, please send the technical details below to the server administrator. More details can be found in the server log. Technical details Remote Address: 172.19.0.1 Request ID: nBJBlhC1AUmFV3QjlOwD

I'm having an issue where all of my downloads fail. I'm able to connect to the Soulseek server and search without any problem, but all of my downloads immediately say "aborted". I have my listening port set (51122) and both it and the obfuscated port (51123) are mapped to the corresponding ports on my host machine. I set up port forwards for both of these ports in my pfSense firewall. I have also tried both checking and unchecking UPnP port mapping and NAT-PMP port mapping (while setting up UPnP on pfSense). None of these things have made any difference. Has anyone else faced a similar issue?

Hi folks, I know people have posted about this before, but I couldn't find any real resolution, so I was hoping someone might be able to point me in the right direction. I have a Cyberpower C670656 UPS connected to my UNRAID server and use the UPS management daemon to monitor it. Over the last few months it has started continually getting the error notification: `Communications restored with UPS Tower`. I get this notification 20-30 times a day, however the UPS seems to be working fine. I've tried changing USB ports, but still get the same notification. Any idea how I can fix this? It's pretty annoying, but I also want to be sure that it doesn't indicate an underlying problem. Thanks in advance!

Yes, you can use the same MariaDB container you use for nextcloud, you'll just need to create a new database for ferdi-server (you can also create a user specific to ferdi-server if you wish). Your existing sqlite database should be in the /app/database folder, however I don't believe you can transfer an sqlite database to MySQL (e.g. MariaDB). Honestly, even if you could I think it would probably just be quicker to start a new database and add your services and login information again.

I figured out what the problem was. The docker container documentation and the UNRAID template had not been correctly updated after a previous update to the Dockerfile. If you update your Recipes directory to map to /app/recipes in the container and the database to map to /app/database your sqlite database should be persistent. I've also updated the UNRAID template, so assuming that it has populated to Community Apps you should be able to just delete your previous app and template and re-pull for the new mount points, if you'd prefer to go that route. I would still recommend using an more robust external database like mariaDB, but if you choose to use the default sqlite database it should at least work properly now. I'm still working on getting SMTP mailing to work correctly, but should be there shortly.

Yeah, that's what I use for this container. It might be worth going with that. In general we recommend using a separate database this container in a production environment.

Strange, I'm sorry to hear that. I hate to say it, but it sounds like you might need to just scrap the container and start from scratch. If you're using the default sqlite database you should be able to find it at /config/database/ In terms of the container updating, the container is designed to pull the newest version of ferdi-server whenever you restart the container, so perhaps you hadn't restarted it in a while? Or hadn't logged in to the web interface lately? It looks like the ferdi-server dashboard was updated in April. The password reset option is a new feature in ferdi-server and I am currently updating the env variables and documentation to get it running. Will hopefully update the image later today or early next week.

This is also something that I'm wondering about as well.

Thanks for the info Loch! It's funny, I must have already done this back when I set up this container as my config was already edited to reflect 1000 episodes per podcast. I must have forgotten, haha.

Hey, sorry, I hadn't seen your post. I haven't had this problem, so I'm not sure exactly how to fix it. Have you tried manually downloading additional episodes? My only other suggestion would be to delete the podcast and re-add with the default to 500, though I know that's not ideal.