CorneliousJD

Thanks for posting this - I don't use this container anymore so I didn't notice it needed this. Much appreciated. i've updated the XML for the template here: https://github.com/CorneliousJD/Docker-Templates/blob/master/recipes.xml It should push live in a few hours to CA. If there's any outstanding issues after this let me know.

Forgot I made this post, but this issue still exists in 6.10.3 currently. Is there any acknowledgement of this issue? The thread linked above seems to show some other users with the same problem.

I changed from a UniFi USG to a UDM now and my old macvlan setup with a VLAN ID of 10 for docker networks to give my pihole a static IP while still using macvlan and avoiding crashes has now stopped working for some reason... and this ipvlan issue still exists. This leaves me in a bad spot now Has this been properly reported as a bug yet?

Easiest option here is to just chmod your /mnt/user/appdata/joplinapp to 0777 that way it should have whatever permission it needs. This seems to be a recent issue with unraid's newer versions where permissions get wonky with containers, LOTS of of them need this type of permission change on new installs, which frankly kind of sucks, but this is the easiest solution to quickly fix yourself.

I'm mobile, but you probably need to chmod the database file to be writable. Try 0777 to see if it allows it to work after that.

This would appear to be unrelated to the container and is a Cloudflare tunnel issue so not something I can really offer any support on. I reverse proxy 3 uptime kuma's with Nginx reverse proxy without any issues at all. Cloudflare is my dynamic DNS provider and I have a letsencrypt wildcard cert on my domain, makes reverse proxy setups dead-simple for me, have never dealt with their tunnels.

Yes the nextcloud performance isn't great by today's standards, but that's nextcloud as a whole to my understanding, but my setup is VASTLY faster than my old LSIO container setup. I had to add my own variable to the Collabora environment. Variable of aliasgroup1 Value of https://cloud.mydomain:443 This is what gives it an allow list of what URL to allow it to load from, working fine for me w/out any issues in nextcloud after that. I also had to reverse proxy my collabora to collabora.mydomain.com and put that in my settings, otherwise it wasn't working. But it's working now and so does co-authoring/guest authoring, etc.

I had started completely over, however I'm sure you could get it to work with your existing data but I had given up on nextcloud for months and started using Filerun instead, but Filerun had it's own problems sadly. This got me motivated to figure out what the heck was going on with Nextcloud again and I started with the official image. My docker config for it is attached, and here's relevant config.php info as well. I even setup Collabra server as a seprate docker and have all that working as well. Passing with A+ security rating and no issues/warnings found in the instance at all, so far so good! It's been a long process to tweak to this point but hopefully this gives you a good starting point! Note that I also setup system cron via unraid userscripts running at */5 * * * * #!/bin/bash docker exec -u www-data Nextcloud php cron.php Sanitized config.php <?php $CONFIG = array ( 'htaccess.RewriteBase' => '/', 'memcache.local' => '\\OC\\Memcache\\APCu', 'apps_paths' => array ( 0 => array ( 'path' => '/var/www/html/apps', 'url' => '/apps', 'writable' => false, ), 1 => array ( 'path' => '/var/www/html/custom_apps', 'url' => '/custom_apps', 'writable' => true, ), ), 'memcache.distributed' => '\\OC\\Memcache\\Redis', 'memcache.locking' => '\\OC\\Memcache\\Redis', 'redis' => array ( 'host' => '10.0.0.10', 'password' => '', 'port' => 6379, ), 'trusted_proxies' => array ( 0 => '10.0.0.10', ), 'instanceid' => 'xxx', 'passwordsalt' => 'xxx', 'secret' => 'xxx', 'trusted_domains' => array ( 0 => '10.0.0.10:8118', 2 => 'cloud.domain.com', ), 'datadirectory' => '/var/www/html/data', 'dbtype' => 'mysql', 'version' => '24.0.3.2', 'overwrite.cli.url' => 'https://cloud.domain.com', 'overwriteprotocol' => 'https', 'trashbin_retention_obligation' => '30, 30', 'default_phone_region' => 'US', 'dbname' => 'nextcloud', 'dbhost' => '10.0.0.10', 'dbport' => '', 'dbtableprefix' => 'oc_', 'mysql.utf8mb4' => true, 'dbuser' => 'nextcloud', 'dbpassword' => 'xxx, 'installed' => true, 'twofactor_enforced' => 'true', 'twofactor_enforced_groups' => array ( 0 => 'admin', ), 'twofactor_enforced_excluded_groups' => array ( ), ***EMAIL CONFIG REDACTED*** 'enable_previews' => true, 'enabledPreviewProviders' => array ( 0 => 'OC\\Preview\\TXT', 1 => 'OC\\Preview\\MarkDown', 2 => 'OC\\Preview\\OpenDocument', 3 => 'OC\\Preview\\PDF', 4 => 'OC\\Preview\\MSOffice2003', 5 => 'OC\\Preview\\MSOfficeDoc', 6 => 'OC\\Preview\\Image', 7 => 'OC\\Preview\\Photoshop', 8 => 'OC\\Preview\\TIFF', 9 => 'OC\\Preview\\SVG', 10 => 'OC\\Preview\\Font', 11 => 'OC\\Preview\\MP3', 12 => 'OC\\Preview\\Movie', 13 => 'OC\\Preview\\MKV', 14 => 'OC\\Preview\\MP4', 15 => 'OC\\Preview\\AVI', ), 'loglevel' => 2, 'maintenance' => false, );

Thanks for the info! My appdata was already on my cache, but I ended up fixing nextcloud performance finally (actually just last week!) The long version here is I abandoned the LSIO container and went with the official apache-based container, spun it up on MariaDB w/ Redis caching, no memory limits (defaults to only 512MB), actually running system cron as recommended, etc, and it's night and day difference in speed, it's amazing, plus the container itself updates the nextcloud instance, no more web-based updater.

IIRC there was an open issue on their github and it has to do w/ the format the videos are in, the browsers cannot play them (major licensing issue) and photoview doesn't do trascoding like emby/plex would, so it just can't play them. I fixed my videos working by disabling HEVC format on my phone, so they record in regular mp4's instead of the hevc-codec and they all work since then - just takes up a bit more storage space per video.

This seems to be the same or a very similar issue, they are experiencing problems much faster than I am, but they seem to have it narrowed down to the same ipvlan issues, and the shim interface where the host access to custom networks being enabled is what causes the problem. Linking here as it may be helpful.

I assume this is a very similar issue that I am facing, my network is fine for a week of uptime but when running a CA Appdata backup where all containers are stopped then restarted my network goes kaput and everything goes down, I cannot reach github, I cannot ping out from the server itself, etc. Just adding my experience to the mix!

This certainly looks like it could be related, for me my network is fine up until I run a CA Appdata backup and then it stops working, very weird. It certainly seems to be ipvlan related for me too!

So this only affects this server. All other devices are ok, and it also *only* happens when doing a CA appdata backup. If I turn off the schedule for backups it doesn't happen at all. Also changing back to macvlan prevents the issue. If it's something network related outside of the server, then it makes no sense to me haha

Hi Squid, it shouldn't, because the only thing that *would* matter is my pihole container, but my server itself is set to use other public DNS servers, plus I run a secondary pihole on a raspberry pi totally external to my server that acts as my backup DNS on my LAN. Since my server itself fails to ping out to 8.8.8.8 when this happens, it would seem to not have anything to do with container order. If I can be of any more help let me know.