xthursdayx

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?

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.

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.

The most recent docker update only changed the readme, so it shouldn't have affected the running of your container at all... This was the commit: https://github.com/getferdi/server-docker/commit/0acd0bf30be6f14e5b0928257e72c0bc8b5e3da7 I just checked my container and I can still log in without any problem. Is it possible that your appdata folder was deleted or something?

Unfortunately I don't have any experience trying to get this to work with Nextcloud Talk. I'm personally using it for voice and video calls from my Matrix Synapse homeserver via Riot and it seems to work just fine. I referred someone else to this guide: https://help.nextcloud.com/t/howto-setup-nextcloud-talk-with-turn-server/30794 and this section of the Nextcloud docs where they talk about using Coturn: https://nextcloud-talk.readthedocs.io/en/latest/TURN/ but it could be that you've already seen these guides. To be honest, I'm not a Coturn expert, so I hope those might help!

To be honest, I'm still experimenting with it myself. Unfortunately I haven't been able to test the container as much I would like, because of the limited number of platforms that actually work with Synclounge (this is apparently an issue with Plex, not Synclounge). For example, Plex Web Player and the Plex PS4 app do not work with Synclounge at present. The main reason I was interested in self-hosting Synclounge was because of privacy concerns rather than performance, because I never actually used the public instance. That being said, if your server has a decent amount of RAM and processing power, you have a strong internet connection, and don't have a huge amount of concurrent users, I would imagine that performance should be better than the public instance, since their hardware might not be up to the current demand as a result of COVID-19... I'm interested to hear how it works out though, so please do post here if you decide to try out this template/container. It will also be a good opportunity to give the developer feedback on the docker container. **EDIT**: It looks like Linuxserver has put out their own Synclounge Docker image since I first created my UNRAID template for Starbix's original Synclounge image. Their image doesn't have an UNRAID template yet, but it may be worth waiting for that, since their container is likely to be kept up to date and have better support the original Synclounge docker container.

Something strange happened last and now I find that all of a sudden none of my subdomain reverse proxies are working. I use this container to host three base domain website, all which are still working, a few subfolder reverse proxies, which are all working, and many subdomains off of two of the base domains, none of which are working any more. I didn't change anything with my setup between yesterday and today and my letsencrypt logs don't show anything suspicious. Any idea how I should go about diagnosing what's going on, or what might be causing this problem? I run pfSense on a standalone box as a firewall and router, so I checked the logs there but also didn't see anything suspicious... **EDIT** I figured out what the problem was. My ISP updated my WAN IP address last night and my dynamic DNS updater had only updated the @ hosts of my domains, not the other subdomains. I'll leave this here in case anyone else runs into the same problem.

The ferdi-server AdonisJS app that is packaged in this docker container has an sqlite db built into it, so you can either use that default database or use an external database, depending on your needs. If you have a high volume ferdi-server then I would recommend using a more robust database, but otherwise the default sqlite db should work fine.