saarg

You use the command I already supplied in a previous post. The abc user is only in the container. Also do chmod -R 777 /dev/dvb You should not have any space in the command either. Use exactly what I have posted.

Then you have not changed the permissions on the adapter correctly in unraid. It should say abc:abc as user.

Are you saying you are installing the drierfor the dvb adapter yourself and it's not using the VB plugin? What does the permissions look like in the container now?

Can you try to remove the tvheadend plugin? Then check/change the permissions and then start the tvheadend container.

Then I don't know what is happening. Did you restart the container after making the changes?

Yes, you do the chown command on the unraid console. The problem is that the abc user (the one running tvheadend) doesn't have write permissions to the adapter. I though the dvb plugin would do a chown and a chmod on the dvb adapter, but I have to ask chbmb.

And if you do the same exec into the container/opening the console from the docker menu? You could try to do a chown -R nobody:users /dev/dvb

Absolutely agree 100.0000%

What is the output of the below command? ls -al /dev/dvb

Thank you for the info. Do you have a sixt sense when it comes to people posting about network? 😁

Did you pass it through to the container?

I'm not sure if docker on unraid has V6 support. Is -6 the correct option? You have supplied nothing from the logs or any error messages, so are to say what the issue is.

Did you do what the post above yours says and do you have a /dev/dri folder after doing it?

Something else is using port 4040 and you have to figure out what. It doesn't make sense that the reverse proxy stops working if you change the host port to 4041 as letsencrypt use the proxynet network bridge and use the container port to communicate, so still 4040. Make sure the context path isn't added again, as that will make the reverse proff not work

There is no mysql database in this container, so using localhost will fail. You need to use the IP (or the container name if on same custom docker bridge) to connect to the container for mysql.

What do you see if you go in the template and click on the show docker allocations text? Is there any other containers using that port?

I think you have to ask unifi about that. We don't make the app, only the container.

If the cert was made using letsencrypt it's not valid until 2034. It's valid for 90 days. If you read the documentation at github you would have seen that you can use the staging variable to test things without getting rate limited. We don't watch spaceinvader videos so we don't know your setup, so if you want help, you need to supply information.

If that is all the info you can give, there isn't much for us to go on.

When a container is updated, unraid first pull the new image, then stops the old container, deletes it and create a new container. If there is an error creating the container, the container is deleted from the list as it have not been created. This is how unraid works, so nothing we can do anything about. You have to find out why the container can't be created again. Force update it and you will se the error. We can't help when you don't post logs or error messages.

You have something invalid in your container template, so when the container is created it fails and therefor is removed from the list as there is no letsencrypt container anymore. Most likely port 80 or 443 is in use. Click add container, choose letsencrypt and hit apply and you will probably see the error.

Ke?

The run command is easily found if you make a change in the container template and hit apply. Just remove a character and add it again and you can hit apply. You have to restart the container for changes to be applied after you copy in a new config. Might have been your cert was renewed and then it loaded the new config you added. You haven't supplied anything else than a small snippet of the log, so hard to say what the issue is. If it would have been an issue with the container, far more people would have reported the issue, so it's most likely a local issue. Do not run any NGINX reload commands inside the container as that will cause what you see.

Both 80 and 443 is already in use. If you are been running commands inside the container that might be the reason. Restart the container and see if the error is still there. Might be a good idea to post your docker run command and what you have changed lately.

Having existing data from unraid in nextcloud in specific places isn't the intended use of nextcloud. Nextcloud is a self hosted cloud solution and not a frontend for unraid shares. You can add the existing mappings using external storage in nextcloud and set which group of users will get access to it. SMB doesn't work in 18.0.4 and will not be fixed until 19 is released.