extrobe

I'd love to see partial-parity scheduling. eg, do 25% each week, meaning a full scan is done every 4 weeks. Currently, doing a full scan takes nearly 25hours, so don't tend to run them unless I have had a dirty restart or something. Being able to phase it would allow users to keep parity in check

Thanks @jude, this did the trick for me in 6.7 stable as well

I asked pretty much the same question on reddit the other day. One of the devs responded that they're working on a change to allow you to force a 'move' when you're mapping a remote path - for this specific reason

I get the same error - 6.7 is the next major release (with a new dashboard etc) that's currently being tested.

Hi - having a bit of trouble with the extended test. It's been 'running' for best part of 3 days now, but don't think it's actually doing anything. On the plugin tab, it says it's processing a specific share ( Status: Processing /mnt/user/wAppDataBackup) , but it's been like that for most of the time it has been running. There's no disk activity, so don't think it's actually doing anything But unsure how to check / force stop / if this is actually normal or not

Thanks trurl, Yes, I did go through those as well, and as far as I can gather, that all looks ok - I used the folder browse button to be extra sure. I've not configured scripts / email templates / password file / admin / logs (latter 2 being the default locations) but I don't use any of these, and in any case, they all default to /config anyway, which I've checked exists within appdata. Perhaps it wasn't SAB - I did have a couple of non-CA store dockers installed which may not have been correctly setup, but thought I'd check it wasn't using an internal folder for unpacking activities. I've just done a full reset of the img file, so going to grab some large files and see how they get on before I add all the more suspect dockers!

Just a quick query I had... what volume does SabNZB use when unpacking (or repairing perhaps) files? From time to time I'm running out of space on the docker image. I've checked every docker app and all volumes are mapped to the cache drive / a user share. The issue seems to get triggered when SAB is unpacking a particularly large file, so wondered if the unpacking process might be the trigger for this? For now, I'm avoiding anything > ~10GB (img is 20GB, of which 8GB is used), but wonder if this might unwarranted and the issue coming from elsewhere. (I'm a little hesitant to stress test my theory as it's a PITA to fix, but thought I'd ask anyway)

I also wonder if there's something better that can be done ref Plex - we all know it's a pain when it comes to backing up, and this accounts for the majority of the backup size. The cache directory doesn't actually need backing up though according to plex documentation. Doesn't help with the masses of metadata files, but would cut the backup size significantly. I'm sure tailoring the plugin to have app-specific behaviours isn't going to be particularly welcome from a development point of view, but Plex feels like a worthy exception.

Sorry if this is a really n00b question - but how would I go about restoring just one of my apps? One of my MariaDB db's seems to have gotten corrupted, but not sure how to go about restoring just that app's data, rather than everything Thanks! Edit: ok - looks like I just need to un-tar the most recent backup and copy the relevant file across - not too onerous-a-job, but would +1 either app-specific tar files or app-specific restore functionality - would cut the restore time down dramatically!

If the PlexmediaServer folder still exists in your appdata folder, you should be fine. Remove any existing dockers. Create a new one using 'my templates' (eg, my-PlexMediaServer) - this should re-use all the mappings you had before. Spin it up - give it a couple of mins to sort itself out, then try connecting. If you still can't connect, check the docker logs

Thanks Squid - I eventually found the very useful Archived Notification menu where it gave me some more detail. I found... So was indeed the temp setting off the failure. I've upped the WARN threshold to 50c, so that should sort it out (it's never less that 38/39, so doesn't take much to get it to 40)

I frequently wake up to a status message on my server stating However, I can't see what the issue is. Some days it's reporting fine - about 50/50 Parity is valid, and last checked a few days ago. When I run fix common problems, there are no errors or warnings Only thing I can think of, is that when mover is running, the cache drive sometimes gets warm (40c-42c) - could this be triggering the FAIL notification?

So, after 3 solid days of trying to get this working - I finally worked out what the underlying issue was - both for being able to 'claim' my original server, form sharing libraries, and remote connections. My MTU size was defaulting to 1500, but was evidently too high! Changed it to 1484 (well, used MSS Clamping instead) and instantly worked. Yikes!

OK - could do with a bit of help on this bit if anyone is able to. I can't currently get remote access to work - but my hunch is that it's my unraid network interface setup Remote access just won't succeed - I'm using Unifi router, with a modem in bridge mode, so there should not be a double-NAT issue. In Plex, i've set 'manual port' to 32400 (I've tried letting uPnP take care of it, and I've tried an alternative port - same results) In Unifi, this port is forwarded to the local IP if I browse to [public facing ip]:32400/web, the plex web interface successfully loads - so I think that rules out a forwarding / nat issue I also have (had) another plex install on another machine, which worked just fine, including remote access. So reckon it's something local to the docker/server I've attached my eth0 setup - it was a bonded connection (bond0) which I hastily turned back to a regular one when I was having a different problem which I thought might be network related, and wonder if I've done something funky which is blocking communications. I'm unsure if the logs can help point towards the issue, but I get a little lost sifting the the logs - not really sure what I'm looking for!

Yes - but didn't manage to get a response. In the end, I backed up the appdata folder, create a fresh Plex install and copied the plugin support, media & metadata folders. This seemed to sort it out. Still have a couple of issues that I might need a hand with (can't get remote access to work, but could be an Unraid network config issue), and problem sharing libraries - but I'll do a bit more troubleshooting before I pop back!

Still having issues getting into Plex. I can claim / unclaim - but as soon as I claim, the server becomes unavailable. - I've tried removing recommended fields from the preferences.xml file - I've tried removing the entire preferences.xml file and going through the basic setup process again - I've tried removing the docker.img file - I've gone ahead with the 6.3.5-->6.4.1 unRaid update Occasionally (depending on what I click on once I've tried claiming), I do get the message...

Hi guys, after bit of help - thought I'd try here before heading over the the Plex forums. Just started my server up after 6 months in storage. Everything is fine, but Plex isn't seeing the server. I can fire up [ip]:32400 but I just get taken to one of my other plex servers and unPlex doesn't appear in the list The only workaround I can find is to go to devices-->server where it does list the unPlex device as being recently active. If I remove it, restart the Plex docker - bam, I can see the server and it prompts me to claim it. However, as soon as I claim it, it disappears again and I have to repeat the process. Any thoughts on what I can do to stop the cycle? Thanks!

There's no existing docker in the CA store for R / R Studio, but there are generic Dockers on Docker.com I went through the process of getting this working with unRaid, and wanted to share how I achieved this. **This is a work in progress!** I'll confess to not really knowing what I'm doing, therefore, some bits may not be quite how they should / could be, but this should get you to a working R Studio Environment. There are a few bits I either think I need / know I want to change - I'll outlines these as well. Prerequisites Already have the Community Applications plugin installed Outstanding: Create a pre-defined XML file (including web gui link & icon) Web gui link now added Icon url now added https proxy via letsencrypt/nginx *turns our https is a R Studio Pro feature only Understanding if the Packages installation directory should be / needs to be a user-defined directory Some progress made on this Outline of the process: Enable Community Applications to search Docker.com Create the share/directory Find the right R Studio Docker Configure the docker template access the web Ui Detailed Process Enable Community Applications to search Docker.com from unRaid, select the Settings tab Under Community Applications banner, select General Settings Near the bottom, find the entry stated 'Enable additional search results from dockerHub?' Change to 'Yes' Apply Done 2. Create the share/directory Create a share or directory dedicated to your R files / Projects. If you have an SSD cache drive, you may want to utilise it, so I would suggest a dedicated share set to use the cache drive only. I used a dedicated share, name r 3. Find the right R Studio Docker There are a variety of R Studio Dockers available. The best ones appear to link back to the Rocker Project. Within the Rocker project, there are various dockers, but I'm using 'tidyverse', which includes the base R code, R Studio and a good selection of the most popular R library's available already added to the docker. From the Apps tab, search 'tidyverse' you should get no results back select 'Get more results from DockerHub' locate the docker 'tidyverse' from the author 'rocker' select 'add' 4. Configure the container You should now be at the container configuration screen. We need to manually map the ports & paths to the container Give your docker a name (if you wish) select 'Add another Path, Port or variable' Config Type: Port Name: HTTP Port Container Port: 8787 Host Port: 8787 connection Type: TCP Add Repeat above step to add another port Config Type: Port name: Shiny Port Container Port: 3838 Host Port: 3838 Connection Type: TCP Add Add another item, but this time a path - this will hold your user-content and workspace session files Config Type: Path Name: Workspace Container Path: /home/rstudio Host Path: /mnt/user/r/ (or whatever share/directory you want to use) Add Add another path item - we will use this space as an install directory for extra library's you add Config Type: Path Name: Custom Library Install Path Container Path: /usr/local/lib/R/custom-library Host Path: /mnt/user/appdata/rstudio At the top-right of the docker add screen, there's a toggle switch that says 'Basic View'. Click this to go to advanced view Where it says 'WebUI', enter http://[IP]:[PORT:8787]/ Where is says 'Icon URL', enter https://cdn.rawgit.com/extrobe/un-r/c7b98d12499aef04180a6bd4f18c77dd2c1155bb/rstudio-icon-s.png Apply this should now pull down and install the docker 5. Access the webUi Browse to http://<yourip>:8787 Login using rstudio/rstudio run the R command .libPaths( c( "/usr/local/lib/R/custom-library",.libPaths()) ) This adds your custom folder to the list of library directories, and sets it as the default. You may want/need to keep this to run as part of your regular R code to ensure the additional libraries are always available. there you have it. Your workspace files should all save into your /mnt/user/r share. I assume the directory where the package files get saved / installed to should be a mapped directory as well. I tried setting this by mapping /usr/local/lib/R to the appdata folder, but this broke it. I'll have another look at it at a later date! That said, I've installed a couple of extra packages, restarted the server and so far they've been persistent. The underlying Docker File does not appear to provide support to install the config/library files to a custom location. Therefore, any packages we add and any settings we change will not be persistent (they won't always get overwritten, but can / does happen, eg with a new docker file being released). We get around the library/package install location by adding a custom library directory.

Wasn't particually suggesting it as a working around - just trying to offer some perspective that whatever has caused the issue is reversible, as it sorted itself out for my without having to rollback to an earlier version. (ps, I'd have also updated the config.php file to add the new IP address to the trusted domains. Those two tweaks are the only things I changed in either docker)

For what it's worth, I was having the same issue. Coincidentally, I was going through the process of changing the IP address (and Subnet) for the server, and updating the dockers etc accordingly. After I updated the NGINX conf file for nextcloud and restarted the letsencrypt docker, everything started working again - and this has continued to be the case since updating both the LE & NC dockers as well. Edit: I also updated the config.php file in nextcloud to add the new IP to the trusted domains list

Funnily enough, I've just upgraded too, and also having issues getting it working again. Slightly different errors from yours mind you - mine appears to start fine, but when I log in I get; [24/May/2017:22:32:04] ENGINE Error in HTTPServer.tick Traceback (most recent call last): File "/opt/sabnzbd/cherrypy/wsgiserver/__init__.py", line 2024, in start self.tick() File "/opt/sabnzbd/cherrypy/wsgiserver/__init__.py", line 2091, in tick s, ssl_env = self.ssl_adapter.wrap(s) File "/opt/sabnzbd/cherrypy/wsgiserver/ssl_builtin.py", line 67, in wrap server_side=True) File "/usr/lib/python2.7/ssl.py", line 363, in wrap_socket _context=self) File "/usr/lib/python2.7/ssl.py", line 611, in __init__ self.do_handshake() File "/usr/lib/python2.7/ssl.py", line 840, in do_handshake self._sslobj.do_handshake() error: [Errno 0] Error If I go into config, it's set to listen on port 8080 - even though it's actually on port 8085 - changing this back to 8085 doesn't fix it either. Also tried unticking https (as I don't use it), but this a) didn't change anything, and b) didn't seem to save the setting anyway. If I look at the logs, it's the same errors as above - no other errors, but various references to starting up the server on port 8090 On my config page (winthin SabNZB), it states the parameters are /opt/sabnzbd/SABnzbd.py --config-file /config --server 0.0.0.0:8080 --https 8090

Worked a charm, thanks (once I'd unpicked all the changes I'd made from the previous attempts!)

Just going through that now - it was my original preference to use dedicatedsubdomain.mydomain.co.uk - only all the guides I found seemed to use this /nextcloud method Is there any reason I should go back and redo the original mariadb & nc setup? It works fine in itself - think it was your tutorial on linuxserver.io i followed in the first place (just didn't go as far as getting apache working at the time)

Hi, after a little bit of help on the config side - but happy to go to a more specific NC group if I'm better off asking there... I've been trying to get SSL / HTTPS access working, so I can access via oc.mydomain.com/nextcloud. I'm using the letsencrypt docker, and been broadly following this walkthrough. As it stands, I've got HTTPS working, and I can browse to https://oc.mydomain.com/nextcloud and it connects fine However, the desktop client now can't connect - on either the original internal address, or the new https address The only address I can get to work in the sync client is https://192.168.0.208:444/nextcloud The error suggest it's looking for the folder/file /owncloud/status.php. What is a little odd, is that whilst I understand that NC is a fork of OC, I can't see that owncloud folder myself anywhere. My nginx config (from the letsencrypt docker) is ... location /nextcloud { include /config/nginx/proxy.conf; proxy_pass https://192.168.0.208:444/nextcloud; } and in nextcloud\nginx\site-confs\default , I changed the install location (as per the walkthrough) # Path to the root of your installation #root /config/www/nextcloud/; root /config/www; I also updated the config.php file to add the below, but didn't seem to impact anything before or after I changed it (I'd already added oc.mydomain.com as a trusted domain) 'trusted_proxies' => ['192.168.0.208'], 'overwritewebroot' => '/nextcloud', 'overwrite.cli.url' => '/nextcloud', #'overwrite.cli.url' => 'https://192.168.0.208:444', Have I missed a step out somewhere? I also tried this - which didn't make any difference either way (could still access via web browser fine) location /nextcloud { include /config/nginx/proxy.conf; proxy_pass https://192.168.0.208:444; } My hunch is that I need to change the value of the 'overwritewebroot' value, but tried a few options here to no positive effect

Here's my take. Works great with dark, but works with light as well.