potjoe

That's because the Nextcloudpi team does not always upgrade the docker image after each update. Updates are done within the container, but each time you edit the template / destroy the image, it pulls the latest image available on dockerhub, which is generally not the latest releases.

Hi @sunpower I don't think Nextcloudpi is officially supported on version 21. But I've been using it with no issue for the past few months. If you have access to the dashboard, check in the applications settings if Nextcloudpi has not been deactivated. If so, just activate it.

What happens if you manually start the update from ncp-panel ? Can you provide the relative log entries ? Log file can be accessed within the container in /var/log/ncp.log

Hi, @outi I spent a LOT of time trying to get a stable solution for this, and ultimately I really think that you should not have the data mounted separately, especially in Unraid. (See here for instance : https://github.com/nextcloud/nextcloudpi/issues/1243#issuecomment-810691176) Nextcloudpi is great, but definitely have trouble maintaining its stability when there are multiple mount points with different filesystems. This is not only a matter of Nextcloudpi not starting : it's random crashes, permissions issues, impossibility to perform upgrades. Moreover, fuse filesystem which is used by Unraid to manage the array is considered to be a "corner case" by Nextcloudpi's team (no criticism intended, it just makes unraid's array irrelevant to store nextcloud data dir as long as it is the case). You should have a dedicated cache drive for Nextcloudpi, that you can mount directly : not with /mnt/user/SHARE, but with /mnt/cache_name/ to avoid fuse. If you want to protect your data on the array, I recommend to mount another share, and to set up Nextcloudpi scheduled backup to this folder. It's not incremental, but it's the best solution in my opinion for now.

You're probably having the same issue mentionned a few messages above. Check in Nextcloudpi panel, System info, I guess "Data directory" is set to /data-ro/nextcloud/data : it should be /data/nextcloud/data. You're not seeing your data in the share because /data-ro/ mountpoint is inside docker.img. You can try what I suggested.

Actually, it is : Network Type is set to "bridge", so you're trying to assign port 80 to this container, already used by Unraid's webui! 2 solutions : keep it in bridge mode, and use different ports for Http and Https (not 80 or 443 then : you can use 1080 or 1443 for instance), or change network type to br0 and assign a static ip address outside DHCP range in "Fixed ip adress" field. You do not need to change WebUI field. Have a look to some local networking introduction course, and then to some content to understand how Unraid and docker are dealing with network. It'll be very useful, and necessary if you're setting up long term services such as nextcloud which needs reliability and accessibility at any given time. To begin with : an IP adress has available any ports between 1 and 65535 to communicate (receive/send) with other IP adresses. Some ports are used by common services, such as SSH on 22, Http on 80, Https 443... You cannot use the same ip with the same port to host two different services. When you're dealing with web services, such as Nextcloud, and you're trying to access it through your web browser : if you're not using standard Http and Https port, then you have to specify the port you want to connect to. For instance, if my Nextcloud service is using port 14443 for https, and uses IP 192.168.0.25, then I would have to type "https://192.168.0.25:14443" to access it. If I only type "https://192.168.0.25", I'm implicitely trying to contact nextcloud on standard https port, 443, which is not assigned to nextcloud in this example.

Just to follow up, host-passthrough mode seems to be working again for me under 6.9 with my ryzen 1600!

Sure! But I advise you to be really careful messing arround with these config files, Nextcloud seems to be really capricious.. BIG warning there once again, backup the data before any modification, and before making the change, be sure to replicate from within the container the content from /data-ro/nextcloud/data to /data/nextcloud/data, including hidden files. Otherwise, you'll just lose access to the data, or Nextcloud won't be able to access it (cause it'll be missing the .ocrdata file). Be careful to keep the same permissions for the files. Then, In the host, not within the container this time, stop the container, go to your data folder under nextcloud/config. You'll find a config.php file. In this file, you can try changing 'datadirectory' => '/data-ro/nextcloud/data', to 'datadirectory' => '/data/nextcloud/data', Again, this is NOT a workaround, I ended up reinstalling from scratch (at one point, Nextcloud just deleted all my files). I suggest to wait for Dimtar's further investigation.

Joining the discussion since I had the same issue a few weeks ago after an update. If you look carefully at the "System info" screenshot you provided, you'll notice that nextcloudpi is setting the data-ro directory as the data directory (datadir). Thing is, data-ro is inside the docker.img, and that's why it's now filled up. I had a real nightmare reverting the change, only fixing the nextcloudpi config file (datadir field actually) ended up in ncp not finding the database and the data, so I finally reinstalled from scratch.... Here the data folder seems to be mapped correctly and recognized inside the container, it's a matter of ncp configuration. I think it happened after an update, 19.0.4 if I'm correct.

You have to copy the previous content inside the new folder, including hidden files. For a few versions now, Nextcloudpi is creating daily backups in the docker img, which is really annoying because all automated backups are suppose to be disabled from nexctloudpi control panel. Does anyone has encounter this behaviour or know how to disable it ? Backups are created in the /var/www/backups repository inside the container.

Hi all, I just noticed a weird behaviour while migrating some docker containers to Ipv6. They appear to be assigned two different ipv6 addresses on the same subnet. Ip addr on a container : eth0@if108: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:42:c0:a8:28:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 192.168.40.4/24 brd 192.168.40.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a01:****:****:**e4:****:****:****:2804/64 scope global dynamic mngtmpaddr valid_lft 86392sec preferred_lft 14392sec inet6 2a01:****:****:**e4::7/64 scope global nodad valid_lft forever preferred_lft forever inet6 fe80::42:c0ff:fea8:2804/64 scope link valid_lft forever preferred_lft forever The 2a01:****:****:**e4::/64 subnet is configured on VLAN 40 with Router Advertisement on a pfsense VM. In Unraid > Settings > Network settings, VLAN 40 is configured with IPV4 and IPV6, and but no ip are assigned (because I don't want to access my server on this subnet, only web services, docker and VMs). Finally, containers are using the br0.40 interface and here is the configuration in Settings > Docker for ipv6 : IPv6 custom network on interface br0.40: Subnet: 2a01:****:****:**e4::/64 Gateway: 2a01:****:****:**e4::1 DHCP pool: not set One last thing, when disabling Router Advertisement on this interface in pfSense, the stateless ip is no longer generated. Only remains 2a01:****:****:**e4::7. Why is this last ip assigned whereas there is no DHCP pool nor RA ? Could it be related to this bug report ? Thanks everyone

Hi unforntunately I was'nt able to sort it out. I still don't know what's causing the issue. I'm currently upgrading my router setup to a pfSense VM, i'll give it another try with the new setup ! Have you any idea where it could come from ?

Absolutely! I tried to perform the challenge with letsencrypt docker in a similar setup (using br0 interface), and it works like a charm. I don't understand why is it any different in this case. I also added my subdomain in the trusted domains list.

Hi! Thanks for all the work and the support. I have an issue with letsencrypt integrated app, I cannot obtain a valid certificate for a subdomain. Nexcloudpi docker uses br0 interface to get it's own ip by the router, so there is no conflict with ports. They are opened in the router, and redirected to the docker's ip. I still have a timeout error when performing the challenge...