Jump to content

chalk

Members
  • Posts

    10
  • Joined

  • Last visited

Posts posted by chalk

  1. On 10/19/2020 at 2:29 PM, chalk said:

     

    I am having this exact same issue.  Prior to enabling "Host access to custom networks" Wireguard worked perfect for over a year.  Since i have made this change it it no longer works.

    How can we raise a bug report for this issue?

  2. On 9/12/2020 at 2:25 AM, deusxanime said:

    I noticed a possible bug/issue with WireGuard on unRAID. I have a docker container that runs on a custom network and I needed it to talk to a container on bridge so I went into docker settings and enabled "Host access to custom networks". After doing so (and all the required stop/start/reboot), the containers could talk on the network and I thought all was well.

     

    Later that week I tried to use my WG VPN tunnel access (LAN access and tunnel through server to my home internet WAN) on my laptop and phone, which I'd used previously and worked great then, since I was on an untrusted Wifi network. After connecting, I was able to access LAN resources on the unRAID server, but could not get the WG client systems to go out to the internet when I had WG turned on on them. I thought back to what had changed and all I could think of was the setting above. So today, since I had to restart unRAID to add a disk, I disabled that setting to test it out and after restarting I tried WG tunnel access and lo and behold it is working again! I can get to LAN resources as well as out to the WAN/internet while connected to WG on the clients.

     

    So it seems like something with enabling the "Host access to custom networks" setting breaks WG's ability to allow VPN clients to tunnel through it and use the WAN while connected.

     

    I am having this exact same issue.  Prior to enabling "Host access to custom networks" Wireguard worked perfect for over a year.  Since i have made this change it it no longer works.

    • Like 1
  3. On 3/2/2019 at 8:53 AM, Piranha2000 said:

    Hi, if you get an error after updating to 15.0.5: Your web server is not properly set up to resolve “/ocm-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. ….

     

    For NGINX add in site-confs/default (replace [NEXTCLOUD]):

     

    location = /.well-known/carddav {
            return 301 $scheme://$host/[NEXTCLOUD]/remote.php/dav;
        }
        location = /.well-known/caldav {
            return 301 $scheme://$host/[NEXTCLOUD]/remote.php/dav;
        }

     

    location = /ocs-provider {

    return 301 $scheme://$host/[NEXTCLOUD]/ocs-provider/;
    }

    location = /ocs-provider/ {
    return 301 $scheme://$host/[NEXTCLOUD]/ocs-provider/;
    }

    location = /ocm-provider {
    return 301 $scheme://$host/[NEXTCLOUD]/ocm-provider/;
    }

    location = /ocm-provider/ {
    return 301 $scheme://$host/[NEXTCLOUD]/ocm-provider/;
    }

     

    This will fix it.

     

    I tried adding this to my nginx configuration but I am still getting the error message.  :(

  4. On 11/4/2018 at 6:32 AM, AncientVale said:

    Hi,

     

    I was currently on Nextcloud 13.05 and the next newest update wasa 14.3, so following the instructions about a page back I initiated the update to 14.03 from within nextcloud itself. That was about 12 hours ago, and when I got to login all I get is 

     

    "This Nextcloud instance is currently in maintenance mode, which may take a while.

    This page will refresh itself when the Nextcloud instance is available again.

    Contact your system administrator if this message persists or appeared unexpectedly.

    Thank you for your patience."

     

    The logs are also unhelpful as the only warnings are:

     

    PHP Warning: require_once(/config/www/nextcloud/lib/versioncheck.php): failed to open stream: No such file or directory in /config/www/nextcloud/cron.php on line 37
    PHP Fatal error: require_once(): Failed opening required '/config/www/nextcloud/lib/versioncheck.php' (include_path='.:/usr/share/php7') in /config/www/nextcloud/cron.php on line 37

     

     

    Any asssstance would be greatly appreciated. This instance was set up using SPO's instructions.

     

     

    I am having the exact same issue.  After doing some digging I was able to correct this issue by doing the following:

     

    From the console of the nextcloud container console run the following command from within the /config/www/nextcloud directory:

     

    sudo -u abc php occ maintenance:mode --off

     

    Rebooted the container and I was able to log back into the old version.

    • Like 1
×
×
  • Create New...