CHBMB

I agree it's a grey area, but I don't think dismissing a distinction between a template and a container should be dismissed outright. It's a difficult balance, and I agree sometimes our containers break with an update, but that's Linux computers. But if it breaks, then at least we can make some effort to look at the container and distinguish if it's a container problem or an upstream app problem, and fix the former and as you say, advise to use a tagged release. If you're solely publishing a template, then there's really nothing you can do. One might argue they are better off without a support thread at all, but I can see the sense in having a place on the forums for Unraid users who want to use that particular container to discuss it, especially as the bar to entry as it were has been lowered considerably. I quite often find an issue is upstream in the application itself, by googling an error code. Nothing I can do about it, and no reason why the person couldn't have done that themselves, but that's the way it goes, but I think we also have to realise that a percentage of the users aren't familiar with github, have no real understanding of the mechanics underlying docker containers and upstream/downstream issues, and there's no reason why they should, that's not what Unraid is about, but we tend to get very different support threads on github than we do here, primarily because it's a different cohort of users, on github it tends to be people who are using their own server with a distro and snapraid or something and docker compose etc whereas here, not necessarily the majority of users are quite as advanced and, (although as we both know there are some seriously advanced users here), it can be pretty basic stuff that trips people up. My point being, would it be wrong to make it clearer that this template purely gives you an easy way to install an application from dockerhub, without the publisher actually having any control over the process. Given a choice between a template to a random dockerhub container that may or may not be official and one of our, @binhex's, or @Djoss container I know which one I'd pick. Was just suggesting that it might be an idea to delineate that a little that's all.

Here you go fellas..... http://www.oldguysruleuk.co.uk/ Although I'm the more mature side of 40, so no spring chicken either.......

There's a few people who just publish XMLs for the Unraid community, I agree it's a bit of a grey area, because as you say, you have absolutely no control upstream whatsoever, I have a few containers for which I've made XMLs for my personal use, but I refuse to publish them here for exactly that reason. I can't even begin to support something I have no control over. Personally I think maybe we shoud look into a sub category for these container templates. @Squid?

Follow the guide I wrote on the linuxserver.io website. I don't support any other method and there shouldn't be any need to touch the default nginx file in the Nexcloud config

Yes, your files are visible on the share. You could have discovered this by looking in the share.... Regards Collabora, the error tells you what's wrong, the SSL cert is self signed. You need to put Nexcloud behind the LetsEncrypt reverse proxy and point Collabora to that URL and it will hit a LetsEncrypt certificate that isn't self signed.

First thing I'd check is you don't have a client machine with a file or folder open. This tends to happen when something is accessing the share.

Try a different tag https://hub.docker.com/r/linuxserver/nextcloud/tags/ Rule of thumb, Generally the tag changes by +1 each week

I can 110% be sure that it's nothing to do with CA. Have you looked on the Nextcloud site to see if it's a problem with Nextcloud itself?

1. Yes 2. No, I installed it a long long time ago before we released the container. 3. MariaDB

Personally I think the days of apps like that are numbered. Most front-end apps like Kodi/Plex/Emby do a pretty good job of scraping what is needed without the need for a further external dependency imho. The idea behind this container is you can run a database on your Unraid server that keeps all your Kodi instances in sync as they all use the central database rather than each individual Kodi instance having it's own database.

I don't but I suspect CPU may be a factor and RAM as I noticed a much quicker response time after I upgraded my server.

@sparklyballs You cheeky bugger!

Stella Artois, colloquially known as wife beater in the UK, due to the effect it has on some of the less respectable members of the population who drink it to excess.......

Try running ls -la /mnt/user0 Shouldn't see any appdata folder at all.

DVB plugin makes all the permission changes automatically. But only if the DVB adapter is present at boot time

User 99 (nobody) Group 100 (users)

That makes no sense as they should be the same location. Have you checked that you've got no appdata files on any of the array drives

Yes and Yes

I think you've missed the point of what this does.

Try replacing ssl_certificate /config/keys/letsencrypt/fullchain.pem; ssl_certificate_key /config/keys/letsencrypt/privkey.pem; ssl_dhparam /config/nginx/dhparams.pem; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; with include /config/nginx/ssl.conf;

Did you click on the bit in the red box. Step by step instructions to do what you want.

Sorry thought the error was in the nginx error log, not the container. Try working out which file in /config/letsencrypt/nginx/site-confs/ is the offending one. My guess is there's somewhere else you've defined a parameter that's conflicting if Nginx isn't starting.

It's something to do with this line in ssl.conf ssl_session_cache shared:SSL:50m; But no idea how to fix it....... Tried obvious things like restarting the container and clearing browser cache? Maybe @aptalca has an idea?

I've got it running on a dedicated subdomain like this. server { listen 80; server_name heimdall.server.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl; server_name heimdall.server.com; include /config/nginx/ssl.conf; location / { proxy_pass https://192.168.0.1:9086; include /config/nginx/proxy.conf; satisfy any; allow 192.168.0.0/24; deny all; auth_basic "Restricted"; auth_basic_user_file /config/nginx/.htpasswd; } }