When using NextCloud as DAV backend with UCS 4.4, OS X is not able to reliably use the function of server detection using ".well-known" due to improper redirects for:

• /.well-known/caldav
• /.well-known/carddav

This can be handled with a proper redirect on (in my case) FQDN level adding in the file /etc/apache2/sites-enabled/default-ssl.conf or the respective template.

Below:

ProxyPass /nextcloud http://127.0.0.1:40000/nextcloud retry=0
ProxyPassReverse /nextcloud http://127.0.0.1:40000/nextcloud

The redirects to the FQDN to be included are:

Redirect 301 /.well-known/carddav https:///nextcloud/remote.php/dav
Redirect 301 /.well-known/caldav https:///nextcloud/remote.php/dav

Additionally it is necessary to have NextCloud and UCS-System on HTTPS as mandatory!!! (Might be enough to mention in handbook.)

This follows the hints in the documentation of NextCloud relating to services discovery: https://docs.nextcloud.com/server/18/admin_manual/issues/general_troubleshooting.html#service-discovery
in case, that - as with UCS - the NextCloud instance is address via /nextcloud.

See also: https://forge.univention.org/bugzilla/show_bug.cgi?id=52008 (closed)

… but yet it should still be possible to do a reinstall. As it happened, a failed update and failed fall back to the previous version, does trigger a remove on UCS and thus leads to removal of data without really having the chance to stop that process → https://help.univention.com/t/nextcloud-upgrade-endup-with-all-data-lost/10420

After fresh install the login page does not open. For some reason, the link on the UCS user page directs to HTTP instead of HTTPS. Correcting the url in the address bar opens the page as it should. Unfortunately there's not a registry entry to fix this, at least that I could see. Any help would be greatly appreciated!

EDIT: Hovering over the Nextcloud link on the UCS page shows that it should connect to the SSL-enabled site, however, clicking on the link takes the user to the HTTP site.

The README.md says that the updatechecker is disabled and updates are provided via Univention App Center. Unfortunately, this doesn't seem to work. An Update of Nextcloud from 11.0.1 to 11.0.2 can be initiated via the Nextcloud webinterface (https://FQDN/nextcloud/index.php/settings/admin → Server settings).

I am aware of this line here, but this doesn't seem to be sufficient.

See also the corresponding entry in the Univention Forum (german)

happens here: https://github.com/nextcloud/univention-app/blob/master/setup#L149-L155

best to set them only on installation.

reported: https://help.univention.com/t/nextcloud-docker-app-having-broken-config/7851

Hi,

my problem is on 17.0.2-0, the cron dont work. On the Weekend i installed the new Version of Nextcloud on a fresh installed Memberserver. At the Moment i have over 20 hours no cron, after i opened the cron.php manually.
I tested it with 3 memberserver and dc master in test area vm on my workstation.
On Nextcloud Memberserver updated from 16.x.x-x all is fine.

Test DC Master over 16 Minutes

Cron is running in container and settings are on 15 minutes

reproduce:
install univention memberserver
install nextcloud app
restart server
show in settings

Symptome:
Cron dont refresh after 15 minutes (after look in crontab and ticket #110)

When a Nextcloud installation in UCS App Center is updated to the next version, additionally installed plugins/apps are not present anymore, like for example the apps "Bookmarks" and "Passman" including their data. See https://help.univention.com/t/nextcloud-upgrade-removes-apps-like-bookmarks-and-passman/11010

Aren't plugins/apps not stored in a specific subfolder in the container? Wouldn't be a good possibility to configure it as volume and make the apps and their data persistent? Are there any side effects on this?

Changing the user name in UCS leads to a new user in Nextcloud. It would be better if Nextcloud identified the users by their entryUUID. The entryUUID never changes and is retained when the user is moved or the user name is changed.

I think something went wrong creating the new 19.03 docker image. The smbclient is missing

see: https://help.univention.com/t/nextcloud-19-0-3-smbclient-missing/16128/2

we are having some latency issues with nextcloud 20, but I've heard nextcloud 21 will improve performance greatly.
are there plans to upgrade to nextcloud 21?

Users reported this issue in the Univention Forum: https://help.univention.com/t/nextcloud-update-13-14-aborting-due-to-backup-error/10978

The 13.0.6 app update introduced an error in this line:

This results in a broken appliance detection and an error with the join script that cannot configure the ldap backend. The fix is to change the line to:

appliance_id=$(ucr get umc/web/appliance/id)

On the Security and Setup Warnings section, the following is displayed:
The "Strict-Transport-Security" HTTP header is not set to at least "15552000" seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips.

The fix is at this site:
https://docs.nextcloud.com/server/13/admin_manual/configuration_server/harden_server.html#use-https

I'm not sure which config file I need to add this to (the Docker container or the UCS server itself):

<VirtualHost *:443>
  ServerName cloud.nextcloud.com
    <IfModule mod_headers.c>
      Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
    </IfModule>
 </VirtualHost>

When will the univention-app updated to Nextcloud 13?

Dear App Maintainer,

Would you consider support for integrating the Nextcloud App "Optical character recognition" available at https://github.com/janis91/ocr into your Nextcloud Docker Container?

When activating this Nextcloud App, I need to add further packages to be run locally in the Nextcloud Docker Container and this breaks later updates of Nextcloud.

If there are no plans to do so, what would be the best way forward to integrate the Nextcloud App "Optical character recognition" or is the only way of installing Nextcloud directly within UCS 4.3?

Best regards,
Peter

The Nextcloud Docker image uses Google's DNS 8.8.8.8 in its /etc/resolv.conf. It therefore can only resolve public domains. Internal hostnames from the intranet served by the UCS environment cannot be resolved by the Docker container.

As a side note, see https://forge.univention.org/bugzilla/show_bug.cgi?id=44845

Multiple Nextcloud Apps are using the gmp library. However, it is not installed within the docker image and no information is provided on how to install it.

Steps to reproduce:

• Install UCS
• Install NextCloud from the AppCenter
• Try to enable for example Bookmarks

Dear App Maintainer,

Would you consider support for integrating the Nextcloud App "Fulltextsearch - Elasticsearch" available at https://github.com/nextcloud/fulltextsearch_elasticsearch into your Nextcloud Docker Container?

When activating this Nextcloud App, I can configure it by referring to an Elasticsearch server outside the Nextcloud Docker Container, but it appears that a connection to this external reference is refused by the Nextcloud Docker Container.

If there are no plans to do so, what would be the best way forward to integrate the Nextcloud App "Fulltextsearch - Elasticsearch" or is the only way of installing Nextcloud directly within UCS 4.3?

Best regards,
Peter

As of today, the underlying Ubuntu 16.04 of the docker image is missing a couple of package updates right after installation (e.g. PHP from 7.0.13 to 7.0.15 and some libs). All of those are categorized as security updates, but there is no mechanism to automatically apply Ubuntu packge updates inside the nextcloud docker app.

If this makes sense at all depends on how often the App itself is updated with a new (up-to-date) docker image. Currently I would opt for adding automatic security updates to the docker image to be safe between App/Image updates.

I guess one needs to combine the "Upgrade within the container" section from http://wiki.univention.de/index.php?title=Docker_Apps/Container_Scripts and something like the unattended-upgrades package from Ubuntu: https://help.ubuntu.com/lts/serverguide/automatic-updates.html

1. Changing the name of a group (or a user) in univention management console UI (UMC) does not change its name in nextcloud. When sharing a folder in nextcloud with this group or user you still have to use its old name or it will not be found.

2. Deleting a user in UMC that shared a folder in nextcloud with a group (without beforehand removing the share or deleting the folder) leads to the folder still being shown in every group member's nextcloud account. There you cannot open or remove the folder. It is an orphan folder ever to exist in the system.

3. This orphan folder eventually causes Nextcloud to stop synching at all.

See also: http://forge.univention.org/bugzilla/show_bug.cgi?id=47178

since Nc 14 the build-in PHP mailer is not supported anymore. With default settings, there is a bug showing a confusing error message to end users: nextcloud/server#12597

→ The mail server should be configured properly, c.f. https://wiki.univention.de/index.php/Integration_with_UCS/Mail

fyi @ngulden

Changing the name of a group or deleting it, isn't reflected in Nextcloud.

Furthermore, when a group doesn't exist in LDAP anymore, but is still in Nextcloud, it cannot be deleted there anymore.

Taken from https://forge.univention.org/bugzilla/show_bug.cgi?id=47178.

@blizzz : Is this still the case?

The inst.sh uses:

NC_MEMBER_OF=`aptitude search univention-ldap-overlay-memberof | grep "^i" -c`

but aptitude is not installed by default anymore on new UCS 4.2 installations. This results in:

/usr/lib/univention-install/50nextcloud.inst: Line 83: aptitude: Command not found.

So aptitude should either be a hard dependency or inst.sh should use something else (e.g. dpkg -l aptitude or dpkg-query -W -f='${Status}\n' aptitude)

UCS and Nextcloud support SAML. This blog article describes how SAML can be setup manually. The blog posting describes where the needed information like URLs and certificates can be found. This information needs to be obtained during the app configuration and provided to the respective sides. I guess, the join script is the best place for those tasks.

In the context of this issue, the app should prepare all necessary settings in Nextcloud and the UCS host to setup the SAML configuration. It consists of the steps for Nextcloud as "Service Provider" and UCS as "Identity Provider".

The setup should allow both, classic LDAP authentication via the Nextcloud login form and single sign-on via the respective login form on UCS as identity provider.

Hello,

in my nextcloud app (13.0.4) on Univention (4.3 errata 126) I get info about APCu not installed but should be installed

Info	cli	Memcache \OC\Memcache\APCu not available for distributed cache
Info	cli	Memcache \OC\Memcache\APCu not available for local cache

Best regards,
Stefan

Univention Forum (german): http://forum.univention.de/viewtopic.php?f=67&t=6573

By default, TLS capable services on a Univention Corporate Server use a TLS certificate that is signed by the (self-signed) UCS CA. The inst.sh validates this certificate by verifying against the UCS CA Root Certificate when using the OCS-API via curl:

curl --cacert /etc/univention/ssl/ucsCA/CAcert.pem -X PUT ...

This works fine as long as the default certificate is used. But services like Apache can easily be configured to use other certificates that are issued by an official CA:
http://sdb.univention.de/1243
http://wiki.univention.de/index.php?title=Cool_Solutions_-_Let%27s_Encrypt
In these cases, the curl commands fail and the config is not written to Nextcloud resulting in a non-working Nextcloud installation.

It should be sufficient to use --capath /etc/ssl/certs/ instead of --cacert /etc/univention/ssl/ucsCA/CAcert.pem, because since UCS 4.1-4 Errata 361, the UCS CA certificate is also linked to /etc/ssl/certs/ (AFAIK it is possible to specify which UCS Version and Errata Level is required for the App in the App Center Provider Portal)

Hi,
Recently I downloaded your appliance to try it out, I was only able to finish the configuration wizard with the hostname I initially wanted: storage-portal-X only when I chose ucs-01 was I able to finish.
This seems like a bug to me.

As a side not in the end I decided not to use the appliance since it denied access to the commandline/backend completely, though I understand the rationale behind it this is still not acceptable to me thus I ended up setting up a similar environment by hand.

Thanks for the very nice work and good luck!

https://apps.nextcloud.com/apps/hsts

This would make the app independent from the main host's web server config. Should be enabled only on new installations. The documentation can be adjusted to point at this as an alternative (need ensure necessary modules are installed and enabled). Appliance behaviour should be tested as well.

While the bruteforce protection is a really nice feature, it's counterproductive in the case of the Univention Nextcloud App, unfortunately. The Univention Nextcloud App is running inside a Docker container and all the network traffic from and to Nextcloud is handled via the Docker bridge interface. This means all logins appear to come from 172.17.42.1 (the IP of the Docker bridge docker0).
This easily leads to situations where everyone is blocked and their logins get delayed.

See also: https://help.univention.com/t/5803 (german)

due to nextcloud/spreed#2806, cf. https://help.univention.com/t/nextcloud-18-0-4-maintenance-mode/14977

• after the first upgrade run, check the stats (or check the log for the exception)
• in error case, rerun the upgrade. if it ran through, turn off maintenance mode

In inst.sh, there are some curl commands doing OCS-APIREQUESTs. If these requests fail, the joinscript finishes with exit 0 nevertheless. This way users get the impression that everything went fine, while in fact nextcloud_add_Administrator_to_admin_group or nextcloud_configure_ldap_backend did not succeed. This results in a broken configuration / installation.

https://help.univention.com/t/univention-nextcloud-join/5057/8 (post 8 and following)
https://help.univention.com/t/nextcloud-ldap-anbindung-fehlt/5704

cf. nextcloud/server#13850

from http://forum.univention.de/viewtopic.php?t=6521&p=25170#p25170

Using a machine account to bind to LDAP needs a method to deal with password changes (see http://docs.software-univention.de/developer-reference-4.1.html#join:secret:change)

Another method is to create a dedicated bind user for the application.

can be run against all files with

shellcheck -e SC1091 $(find . -type f -exec file --mime-type {} + | grep 'text/x-shellscript' | cut -d ':' -f1) 

Hi,

today i installed a fresh Univention Memberserver for Nextcloud 17.0.2-0.

Yesterday i uninstalled an backup all Data of 16.0.6-0.
After install and config i let all data sync back in the cloud.

Now i show in the webgui, i have the well-known warning again.
My davX on android cant connect with the Server. The normal Nextcloud app is connected with the Server.

Here is my System detail:
https://cloud.c-lab.one/nextcloud/s/JEy9Cso7FqgJj9P
vEe7opdNdTjic53gbqE9

at the moment i use the apache2 workaround:
Redirect 301 /.well-known/carddav /nextcloud/remote.php/dav
Redirect 301 /.well-known/caldav /nextcloud/remote.php/dav

I hope you can help me to solve it and its not a version problem :/

Best Regards

I should be thought about changing the LDAP configuration to use LDAPS per default. See https://help.univention.com/t/nextcloud-ldaps/10370 on how this can be done for the moment.

Maybe a documentation is already sufficient enough. I heard such request only one time.

thus upgrading from appstore fails

it was backported to stable16 in the server repo eventually

If I restrict the visibility of apps to several user groups (e.g. "Domain Admins") and update the nextcloud App via the app center, then the app visibility is reset so that every user can see the apps again.

AFAIK are the visibility settings app-specific and need therefore be kept between updates.

… we already disable it, but it is easy for admins to turn it on and cause havoc. Updates on UCS shall be done via UCS, another mechanism is not supported on this platform.

Hi,

there is a problem with the installation of the nextcloud App if the Administrator account has no displayName LDAP attribute:

-> udm users/user modify --dn "uid=Administrator,cn=users,$(ucr get ldap/base)" \
    --set displayName=""`
-> univention-ldapsearch uid=Administrator | grep -i displ
-> univention-app install nextcloud
-> univention-check-join-status 
Warning: 'nextcloud' is not configured.
Error: Not all install files configured: 1 missing

And the /var/log/univention/join.log ...

-> more /var/log/univention/join.log | grep -B 2 -A 2 Administrator
 <data/>
</ocs>
modifying uid=Administrator,cn=users,dc=four,dc=three ..
Object modified: uid=Administrator,cn=users,dc=four,dc=three
modifying uid=ucs-sso,cn=users,dc=four,dc=three ..
Object modified: uid=ucs-sso,cn=users,dc=four,dc=three
--
modifying uid=dns-master,cn=users,dc=four,dc=three ..
Object modified: uid=dns-master,cn=users,dc=four,dc=three
Could not Administrator to admin group, because user was not found:
<?xml version="1.0"?> <ocs> <meta> <status>ok</status> 
<statuscode>200</statuscode> <message>OK</message> </meta>
<data> <users/> </data> </ocs>

The reason seems to be the LDAP filter in the user_ldap app when searching for users. With log turned on, i can see:

{"reqId":"QY5OhvbrJC8X2T3VrI8m","level":0,"time":"May 16, 2018 10:52:46","remoteAddr":"10.200.7.160","user":"nc_admin","app":"user_ldap","method":"GET","url":"\/nextcloud\/ocs\/v2.php\/cloud\/users?search=Administrator","message":"initializing paged search for Filter (&(&(objectclass=nextcloudUser)(nextcloudEnabled=1))(displayName=*)(|(uid=Administrator*)(givenName=Administrator*)(sn=Administrator*)(employeeNumber=Administrator*)(mailPrimaryAddress=Administrator*))) base Array\n(\n [0] => dc=four,dc=three\n)\n attr Array\n(\n [0] => dn\n [1] => uid\n [2] => samaccountname\n [3] => memberof\n [4] => nextcloudQuota\n [5] => mailPrimaryAddress\n [6] => displayName\n [7] => \n)\n limit 500 offset 0","userAgent":"curl\/7.52.1","version":"12.0.5.3"}

This filter does not find my Administrator account as it requires the displayName LDAP attribute (displayName=*).

Impact:

• In a standard setup the Administrator account has a displayName so it is not that big of a problem (but nothing prevents me from deleting this attribute)
• But in a AD Member mode setup (UCS is a "slave" to an ad server, all accounts are synced unidirectional to the UCS system) this is very annoying, because the standard Administrator in ad servers does not have a displayName

best regards,
Felix

i would like to ask when the ucs app is planned to be updated to 19 according to some people 19 is already released in production

Updated from Nextcloud 11.0.1 to 11.0.2 via univention app center and the crontab entry within the docker image got lost.

At least, it doesn't exist YET - I found out by reading the nextcloud message saying that last cron execution was 20 hours ago. Cannot say whether or not it existed before, but crons had been executed.

After creating /etc/conf.d/nextcloud manually, all works fine now.

the line should reflect the new docs: https://docs.nextcloud.com/server/17/admin_manual/configuration_server/background_jobs_configuration.html

so should be:
echo "*/5 * * * * www-data php -f /var/www/html/cron.php" > /etc/cron.d/nextcloud

Some UCS administrators have the demand to change settings in the php.ini like upload_max_filesize.

If an admin connects to the running container and changes the php settings under: /etc/php/7.2/apache2/php.ini or /etc/php/7.2/apache2/conf.d/60-nextcloud.ini then these settings aren't persistent over updates.

I described a workaround using docker volumes here https://help.univention.com/t/howto-nextcloud-raise-php-upload-max-filesize/15279, which is error-prone and complicated.

So please provide a way to overwrite the default PHP settings.

I suggest adding the 60-nextcloud.ini as an additional volume.

There is already solution to avoid this in the univention forum:
https://help.univention.com/t/nextcloud-login-problem-after-upgrade-from-20-0-2-to-20-0-8/17554

But this will disable talk/spreed.

I have the following log-message:
{"reqId":"5viCGhVgA03SaqZ6pMlH","level":4,"time":"2021-03-24T18:29:15+00:00","remoteAddr":"MYIP","user":"MYUSER","app":"webdav","method":"PROPFIND","url":"/remote.php/dav/files/MYUSER/","message":{"Exception":"Sabre\DAV\Exception\ServiceUnavailable","Message":"Doctrine\DBAL\Exception\TableNotFoundException: An exception occurred while executing 'SELECT "r"., "p". FROM "oc_talk_rooms" "r" LEFT JOIN "oc_talk_participants" "p" ON ("p"."user_id" = ?) AND ("p"."room_id" = "r"."id") WHERE "p"."user_id" IS NOT NULL' with params ["MYUSER"]:\n\nSQLSTATE[42P01]: Undefined table: 7 FEHLER: Relation »oc_talk_participants« existiert nicht\nLINE 1: ...T "r"., "p". FROM "oc_talk_rooms" "r" LEFT JOIN "oc_talk_p...\n ^","Code":0,"Trace":[{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php","line":192,"function":"check","class":"OCA\DAV\Connector\Sabre\Auth","type":"->"},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php","line":144,"function":"check","class":"Sabre\DAV\Auth\Plugin","type":"->"},{"file":"/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"beforeMethod","class":"Sabre\DAV\Auth\Plugin","type":"->"},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":458,"function":"emit","class":"Sabre\DAV\Server","type":"->"},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":251,"function":"invokeMethod","class":"Sabre\DAV\Server","type":"->"},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":319,"function":"start","class":"Sabre\DAV\Server","type":"->"},{"file":"/var/www/html/apps/dav/lib/Server.php","line":332,"function":"exec","class":"Sabre\DAV\Server","type":"->"},{"file":"/var/www/html/apps/dav/appinfo/v2/remote.php","line":35,"function":"exec","class":"OCA\DAV\Server","type":"->"},{"file":"/var/www/html/remote.php","line":167,"args":["/var/www/html/apps/dav/appinfo/v2/remote.php"],"function":"require_once"}],"File":"/var/www/html/apps/dav/lib/Connector/Sabre/Auth.php","Line":163,"CustomMessage":"--"},"userAgent":"Mozilla/5.0 (Macintosh) mirall/3.1.3git (build 4850) (Nextcloud)","version":"20.0.8.1","id":"605b8518bf583"}

Hi,
nextcloud_modify_users() in the join script overwrites the multivalue setting "serviceprovider" for users. This can break saml for "other" service providers.

Please change "--set" to "--append" in nextcloud_modify_users() for the "serviceprovider" attribute:

--- inst.o	2020-03-12 14:49:39.116000000 +0100
+++ inst	2020-03-12 14:49:35.404000000 +0100
@@ -396,7 +396,7 @@
         udm users/user modify "$@" --dn "$dn" \
             --set nextcloudEnabled="$nextcloud_ucs_userEnabled" \
             --set nextcloudQuota="$nextcloud_ucs_userQuota" \
-            --set serviceprovider="$SP_DN"
+            --append serviceprovider="$SP_DN"
     done
 }
 

Best regards,
Felix

I manually configured the 'defaultapp' parameter inside the container at /var/www/html/config/config.php. Then I updated the app from 13.0.4 to 13.0.5 (UCS 4.3-1).
After the update, the config at /var/www/html/config/config.php was replaced with /var/lib/univention-appcenter/apps/nextcloud/conf/config/config.php. The 'defaultapp' I had configured earlier was lost. So I suppose the config /var/www/html/config/config.php wasn't copied to /var/lib/univention-appcenter/apps/nextcloud/conf/config/config.php, which would be the expected behaviour, I believe?

So the workflow to configure something manually for the app and update the app would be as follows:

• Install an editor inside the container
• Change /var/www/html/config/config.php inside the container to have the config applied immediately
• Change /var/lib/univention-appcenter/apps/nextcloud/conf/config/config.php so the config survives app updates
• Update app

I think it might be a good idea to just mount /var/lib/univention-appcenter/apps/nextcloud/conf/config/ at /var/www/html/config inside the container. That way the app wouldn't even have to copy the config around because it would be stored safely on the host and mounted to the desired place.

A regular use case seems to be to add SMB shares as External Storage to Nextcloud: https://docs.nextcloud.com/server/11/admin_manual/configuration_files/external_storage/smb.html (especially with UCS, which is usually also used as Fileserver).

This is currently not possible with the univention-app, because there is no smbclient in the docker image available. Adding the package php-smbclient to the docker image would be the first step to enable this feature.

There is a topic in the Univention Forum (german): http://forum.univention.de/viewtopic.php?f=67&t=6558

This client was able to connect to Nextcloud 10 but fails when connecting to the new version. I've not tested platforms other than Univention so I'm not sure if this is specific to this docker instance. Please advise.

EDIT: It seems the client has it hard-coded that the trailing URL should be owncloud instead of nextcloud or looking for status.php in the root. I am able to connect to https://mail.sixshooterz.com/nextcloud/status.php without issue.