Thunderbird-Lightening-Cardbook Caldav & Carddav broken after upgrade to Nextcloud 11

Hi All,

I love the new features in Nextcloud 11! Thanks.

But I’m afraid that the Carddav and CalDav connections for Thunderbird no longer work. They both work fine with my Android device. I’m unclear how I might provide more information. There doesn’t not appear to be any mention of a problem in neither nginx or nextcloud logs.

Nextcloud 11.0.1
Nginx
Ubuntu 16.04

For now I’ll roll back to my version 10.

Thanks,
Wayne

I am using Lightning, that works fine, carddav was always bad in thunderbird, I has sync issues in several nc versions.

Hi Wayne,

I had run into exactly the same problem as you with my setup - my Thunderbird (Lightning and CardDav for proper contacts sync) simply stopped working - the error was READ_FAIL and DAV_NOT_DAV.

Everything else seemed to work without issues though, Android Dav sync, WebDav. I even installed eM client as an alternative desktop client and it managed to sync contacts and calendar.

What was noticeable was that Thunderbird did not even ask for username and password. It simply failed. I did however manage to resolve my situation.

For whatever reason unknown to me Nginx seemed to have messed up my setup. In my case I used nginx as reverse proxy so simply deactivating it resolved the situation immediatly.

I am not sure about your setup but it might have something to do with the nginx configuration.

I hope that helps, let us know if you find out anything new.

Cheers,
rien

Thanks for the note Rien… (C’etait plus que rien).

This is my Nginx config file… I’m certainly not an expert on website configuration… see anything out of order in it?

server {
listen 80;
server_name cloud.gregorigroup.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
server_name cloud.gregorigroup.com;
root /var/www/nextcloud;

ssl on;
ssl_certificate /etc/letsencrypt/live/cloud.gregorigroup.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/cloud.gregorigroup.com/privkey.pem;




add_header Strict-Transport-Security "max-age=15552000; includeSubDomains";
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;


access_log  /var/log/nginx/nextcloud.access.log;
error_log   /var/log/nginx/nextcloud.error.log;

location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
}

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

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

client_max_body_size 512M;
fastcgi_buffers 64 4K;
gzip off;

error_page 403 /core/templates/403.php;
error_page 404 /core/templates/404.php;

location / {
    rewrite ^ /index.php$uri;
}

location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
    deny all;
}

location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
    deny all;
}

location ~^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
    include fastcgi_params;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param HTTPS on;
    #Avoid sending the security headers twice
    fastcgi_param modHeadersAvailable true;
    fastcgi_param front_controller_active true;
    fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
    fastcgi_intercept_errors on;
    fastcgi_request_buffering off;
}

location ~ ^/(?:updater|ocs-provider)(?:$|/) {
    try_files $uri/ =404;
    index index.php;
}

location ~* \.(?:css|js)$ {
    try_files $uri /index.php$uri$is_args$args;
    add_header Cache-Control "public, max-age=7200";
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;
    # Optional: Don't log access to assets
    access_log off;
}

location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
    try_files $uri /index.php$uri$is_args$args;
    access_log off;
}

location ~ /\.ht {
    deny all;
}

}

Hi Wayne,

first off, I really don’t know much about web server administration at all, so I hope someone more seasoned can help out right here.

From my investigation it appears that Thunderbird handles the path rewrites not as well as other clients. To confirm this theory, have you been able to try to connect to CardDav/CalDav with other desktop clients? I tried eM client to investigate and that one worked just fine.

Other than that I cannot spot anything in your config that looks fishy. So I am afraid I would not be able to help further if it was anything else.

Cheers,
rien

Figured it out!

When i was configuring Letsencrypt for my https connection I had commented out all of previous ssl directives… Once letsencrypt was completed and my sessions were secured I didn’t think any of the other directives were necessary… the one that Thunderbird needed was

ssl_protocols              TLSv1 TLSv1.1 TLSv1.2;

once that was added it all worked great.

All the necessary ssl directives for Nginx config are

ssl on;
ssl_certificate /etc/letsencrypt/live/cloud.gregorigroup.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/cloud.gregorigroup.com/privkey.pem;
ssl_session_timeout 5m;
ssl_ciphers               'AES128+EECDH:AES128+EDH:!aNULL';
ssl_protocols              TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;

Thanks
Wayne

1 Like

Ah, good to know! That came from a different angle.

Which reminds me of a curious situation when I first configured nextcloud (with Let’s Encrypt) and Thunderbird. Thunderbird just wouldn’t connect until I found out that Let’s Encrypt was simply not activated as trusted authority. I never found out why that was the case, luckily that was easy to fix on client side.

Glad you figured it out. Always something new.

Cheers,
rien

Hey i had this problem too. The link which was used in NC10 has changed in NC11 so check your link in the plugin. Also the Contact link changed :frowning:
I guess a solution is to delete and add calendars and contacts links again. Another solution would be a rewrite rule in apache or nginx.

Servus

Gentleman,

I believe that this solution MAY work indeed - however… I had the same problem till about 5 minutes ago BUT only in one out of 5 of my Thunderbird installations.

Yes I use nginx. Yes I switched from StartSSL to Letsencrypt recently. Yes I migrated from OwnCloud to NextCloud over the past weekend.

For me - changing the Nginx settings made no sense… It worked on 4 machines and only one refused to connect. I knew that the url and password were correct… Your post gave me an idea.

Steps that solved the issue for me:

A) Close Thunderbird

B) Go to your Thunderbird profile:

On Linux its ~/.thunderbird/RANDOMSTRING.default/

C) Find file cert8.db and rename it to old.cert.db

D) Restart Thunderbird

That’s it. Your Thunderbird should now ask you for the CalDav resources login and password.

Regards.

Andrzej

1 Like

I tried these steps and had no luck.
TB did not ask for login and password and the problem remains.

I also tried to redo the SSL configuration but that did not help either. However, I am not sure wether I did that correctly as I am using Apache, so I had to “translate” some of the configuration.

Thank you for your post ! For me it works !