Tophicles

I have a failed disk (disk 16, not that it matters) and it crapped out during a resierfsck. I know, I know, I should have them as XFS. Anyway, it was going through a resiserfsck --rebuild-tree and the system crashed (power outage past UPS runtime). Now it was showing as "unmountable, no file system" - to be safe I swapped it with a new disk and it went through the disk-rebuild. Now I've got the new disk showing as "unmountable, no file system". I supposed it transferred the wrecked data over to the new drive. I'd rather avoid taking the entire array offline to scan/fix the disk (if it even will) and, when trolling the intertubes, I saw someone saying you don't need to unmount the entire array, just the problematic drive? IS this correct?

I'm chiming in too, I have a TP-LINK c5400 and I see nothing in there...

That's what I have blanked... the first one is an (optional) source network IP. Don't need that in that any of the other NAT rules I have that are working. I just blanked it out of habit.... lol

So I'm having a b**ch of a time trying to expose my Nextcloud docker to the internet. I have OwnCloud running already (works fine). I have installed the docker and pointed it at port 8888 (which is NAT forwarded on my router to my unraid host IP, same as owncloud). The config.php is allowing my external domain and internal scope as trusted networks (same as owncloud): <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'ocjd0rpgflo6', 'passwordsalt' => 'ssssshhhhhh', 'secret' => 'sssshhhhhh', 'trusted_domains' => array ( 0 => 'xxx.xxx.xxx.xxx:8888', 1 => 'myhost.mydomain.com:8888', ), 'overwrite.cli.url' => 'https://xxx.xxx.xxx.xxx:8888', 'dbtype' => 'sqlite3', 'version' => '12.0.0.29', 'dbname' => 'nextcloud', 'dbhost' => 'xxx.xxx.xxx.xxx:3306', 'dbport' => '', 'dbtableprefix' => 'oc_', 'mysql.utf8mb4' => true, 'dbuser' => 'oc_tophicles', 'dbpassword' => 'mydbpass', 'installed' => true, ); No matter what I cannot get to this from the outside. I've tried numerous ports, no luck. The port forward on my router is attached as a PNG. Everything else is standard as the docker has installed in as far as nginx configurations etc. Here's the output from the docker launch: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="nextcloud" --net="bridge" -e TZ="America/New_York" -e HOST_OS="unRAID" -e "PUID"="99" -e "PGID"="100" -p 8888:443/tcp -v "/mnt/user/nextcloud/":"/data":rw -v "/mnt/extra/dockers/nextcloud":"/config":rw linuxserver/nextcloud c582df2eaf02da6e3a22910e047c6f7c2fccbdfb29e17a480373d1f13218b92f The command finished successfully! It seems that something is blocking the NAT but I don't know what. No stranger to port forwarding, just totally lost on this one. do I *have* to setup a reverse-proxy to get this outside? I shouldn't think so, but most guides seem to have this as a component. Any pointers would be greatly appreciated, any clarification or supplemental information can be given upon request. Thank you for your time

Any chance for the 4.1 update?

Just a quick note of thanks for still updating the plugin! Not all of us are excited about Dockers

There is no supported cache_dirs plugin available at the moment. The one that was available at one point was withdrawn at the request of Joe L. (the author of cache-dirs.). I actually just re-read that in the back posts... didn't mean to stir anything up...

Agreed, this is a must-have in my humble opinion! Now, one quick question, how do you get the new version of the cache_dirs to work with the plugin? (or is there an updated version of the cache_dirs plugin?)

You have it running under 6b6? If so, what did you have to do to get it working?

Has there been any movement on the 64bit version of cache_dirs? This plugin made a HUGE difference on my 5.X unRAID and I'd love to see it resurface for 6

Just my 0.02 worth here I recently started using this (marvelous) plugin, great work! I am running the simplefeatures web server plugin for my NEWZNAB server. I wanted to add "virtual hosts" to this so I could run the php front end to virtual box. I decided to run my newznab host on port 85 and my phpvbox on port 84. For those who are curious, here's what you add to the lighthttp.cfg in /boot/config/plugins/simplefeatures/ : This code sets up the "host" for NEWZNAB, as well as the particular URL re-writing rules that the code requires. Originally this was a global configuration, and I couldn't figure out why my PHPVBOX wasn't working! It was because the URL-rewriting was effing things up # User customizations # Add your own settings here. These won't get overwritten upon reboot # $SERVER["socket"] == ":85" { url.rewrite-once = ( "^/.*\.(css|jpg|jpeg|gif|png|js|ico)" => "$0", "^/(admin|install).*$" => "$0", "^/([^/\.]+)/?(?:\?(.*))$" => "index.php?page=$1&$2", "^/([^/\.]+)/?$" => "index.php?page=$1", "^/([^/\.]+)/([^/]+)/?(?:\?(.*))$" => "index.php?page=$1&id=$2&$3", "^/([^/\.]+)/([^/]+)/?$" => "index.php?page=$1&id=$2", "^/([^/\.]+)/([^/]+)/([^/]+)/?$" => "index.php?page=$1&id=$2&subpage=$3" ) } This code sets up the "host" for PHPVBOX $SERVER["socket"] == ":84" { server.document-root = "/mnt/extra/phpvbox/" } This is just an example of how to have yet another "host" running on a different port. This way you can house different sites. $SERVER["socket"] == ":83" { server.document-root = "/mnt/extra/sandbox/" } It might not be perfect, but it's working for me