saarg

You can't change the port to 1800 as the client looks for port 1900 as far as I know. The only solution to having multiple DLNA servers on the same server is to set each container to its own IP.

Using the console entry in the menu takes you inside the container. Same as docker exec using SSH to unraid. MariaDB has a built in client, but refer to the MariaDB documentation for how to use it.

From where are you browsing to tautulli? If it's from a VM on unraid, you will not manage to access it. It's a security feature in macvlan.

In Jellyfin or DLNA in general?

It's probably caused by docker having its own IP range and sees your local network as remote. There might be a settings file you can edit, but I do not know which or where. Might be better to ask jellyfin. Unless binhex knows.

Don't run commands to renew the certificate yourself. Is your time and date in unraid correct? You can trigger an update by simply adding a subdomain. After that, you can remove it.

You have probably used a port already in use

Either read a little further up the page or click the github link in the first post.

Probably best to post this over at the Plex forum.

You need to check the MariaDB documentation for how to connect to the database. You can do this through the console or remotely.

It's the command you get on the pop-up when you change anything in the container template or update the container. It's not a command you have to run manually. Check the docker faq. It's linked to in my signature. If you don't see the signature you need to turn on signatures in your profile settings.

These are not normal errors, so there is something wrong somewhere in you setup. Looks like a database error, so might be your mariadb container. Post the docker run command for nextcloud and mariadb.

Try setting the client_max_body_size in the default file of nextcloud to 0 instead of 10G and see if that helps. Remember to restart the container after the change.

Have you installed any of the containers before at one point? You can verify this by checking the files I mentioned earlier. They are in the appdata folders of the containers.

Have you had this setup for a long time? Then it might be time to delete some of the config files in both letsencrypt and nextcloud container. It will then be recreated, but using the latest one. There is a date at the top of the files and if you don't have any date, it's very old. In letsencrypt it's these files: default nginx.conf proxy.conf ssl.conf In Nextcloud: default Remember to back up the files first, but do not keep the backups in the same folder as the original file. Do you use our reverse proxy config?

Sorry about that. Was on the phone when reading the post, so not so easy to read the xml. As long as you don't use an existing address, it should be fine, but the changes might get lost if you edit the VM template at one point. It is indeed strange that just changing the host address makes pfsense see the passed through card.

You can't just change the PCI number in the xml like that. The PCI number is the ID (not really, but for this example, let's pretend it is) of the card that is passed through to the VM. If you change it, you pass through another device. The PCI devices list will tell you the PCI number of the device. Post the list (under tools) and also which brand and model the card is.

Can you try using the previous tag on docker hub? Link in the first post.

You always have to update either through the webui or command line on our Nextcloud container. It's one of the few containers we have that doesn't get updated by updating the container.

It's only on big setups it will take a long time. For most users here, it's going to be a short wait.

Read the posts above to understand what to do. You are running the command on the unraid command line and sudo using root, which is completely wrong.

It says at the bottom of the documentation linked in your link to put nextcloud in maintenance mode.

Check our blog on linuxserver.io for the Customizing our containers post. Then it will survive an update. Can you add a github issue for the request. Knowing myself, I will most likely forget it when I wake up tomorrow.

If you come across it, which you probably will since it was a new change, just run the commands in the documentation and the relevant bits in the database will be converted. Remember to modify the command to work for the container. The correct user and php bit is in the command line upgrade instructions linked in the first post.

It should work now. We forgot to set up the external trigger for the build job, so a new image was only pushed if there was an updated OS package found. Sorry about that. The newest build should be ready soon.