Nginx documentation (Unofficial (Community) )

Hey,

it seems the ownCloud team has decided to drop any reference to Nginx from the official documentation without providing a new home to preserve this important but now dropped information around Nginx and ownCloud (yet?).

Nginx is the second most widely web server after Apache with a lot users within the ownCloud community so i have decided to take the chance and preserve the content in this new thread.

Note: I have copied the content to the best of my knowledge and i’m not the author of the content. Please use this information with caution as i can’t give any guarantee for the correctness of it.

Table of Content

Nginx configuration
Nginx with Let’s Encrypt
Big File Upload Configuration (> 512MB)
Troubleshooting
Log Optimisation
Performance Tuning

Background

1 Like

Nginx Configuration

Note: " in the web root" known to work with ownCloud 10.0-10.3 (older/newer versions as well as subdirectory config untested)

Introduction

This page covers example Nginx configurations to use with running an ownCloud server. Note that Nginx is not officially supported, and this page is community-maintained. Thank you, contributors!

  • Depending on your setup, you need to insert the code examples into your Nginx configuration file.
  • Adjust server_name, root, ssl_certificate, ssl_certificate_key ect. to suit your needs.
  • Make sure your SSL certificates are readable by the server (see Nginx HTTP SSL Module documentation).
  • Nginx configuration blocks inherit add_header directives from their enclosing blocks, so you just need to place the add_header directive in the top‑level server block. There’s one important exception:
    if a block includes an add_header directive itself, it does not inherit headers from enclosing blocks,
    and you need to redeclare all add_header directives or reinclude them.
  • Because Nginx does not allow nested if directives, you need to use the map directive.
    The position of a location directive connected to the result of the map directive is important for success.

TIP: For better readability, it is possible and advised to move common add_header directives into a separate file and include that file wherever necessary. However, each add_header directive must be written in a single line to prevent connection problems with sync clients.

TIP: The same is true for map directives which also can be collected into a singe file and then be included.

Example Configurations

CAUTION: Be careful about line breaks if you copy the examples, as long lines may be broken for page formatting.

You can use ownCloud over plain HTTP. However, we strongly encourage you to use SSL/TLS to encrypt all of your server traffic and to protect users’ logins, and their data while it is in transit. To use plain HTTP:

  1. Remove the server block containing the redirect
  2. Change listen 443 ssl http2 to listen 80;
  3. Remove all ssl_ entries.
  4. Remove fastcgi_params HTTPS on;

Note 1

fastcgi_buffers 8 4K;
  • Do not set the number of buffers to greater than 63. In our example, it is set to 8.
  • If you exceed this maximum, big file downloads may consume a lot of system memory over time. This is especially problematic on low-memory systems.

Note 2

fastcgi_ignore_headers X-Accel-Buffering
  • From ownCloud version 10.0.4 on, a header will be sent to Nginx not to use buffers to avoid problems with problematic fastcgi_buffers values. See note above.
  • If the values of fastcgi_buffers are properly set and no problems are expected, you can use this directive to reenable buffering overriding the sent header.
  • In case you use an earlier version of ownCloud or can´t change the buffers, or can´t remove a existing ignore header directive, you can explicitly enable following directive in the location block fastcgi_buffering off;

NOTE: The directives fastcgi_ignore_headers X-Accel-Buffering; and fastcgi_buffering off; can be used separately but not together.

Note 3

TIP: Raymii.org provides an excellent introduction to strong SSL security measures with Nginx.

ownCloud in the web root of Nginx

The following config should be used when ownCloud is placed in the web root of your Nginx installation.

The configuration assumes that ownCloud is installed in /var/www/owncloud and is accessed via http(s)://cloud.example.com.

upstream php-handler {
    server 127.0.0.1:9000;
    #server unix:/var/run/php7.2-fpm.sock;
}

server {
    listen 80;
    listen [::]:80;
    server_name cloud.example.com;

    # For SSL certificate verification, this needs to be served via HTTP
    location /.well-known/(acme-challenge|pki-validation)/ {
        root /var/www/owncloud; # Specify here where the challenge file is placed
    }

    # enforce https
    location / {
        return 301 https://$server_name:443$request_uri; # Change 443 if using a custom HTTPS port
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name cloud.example.com;

    ssl_certificate /etc/ssl/nginx/cloud.example.com.crt;
    ssl_certificate_key /etc/ssl/nginx/cloud.example.com.key;

    # Example SSL/TLS configuration. Please read into the manual of Nginx before applying these.
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers "-ALL:EECDH+AES256:EDH+AES256:AES256-SHA:EECDH+AES:EDH+AES:!ADH:!NULL:!aNULL:!eNULL:!EXPORT:!LOW:!MD5:!3DES:!PSK:!SRP:!DSS:!AESGCM:!RC4";
    ssl_dhparam /etc/nginx/dh4096.pem;
    ssl_prefer_server_ciphers on;
    keepalive_timeout    70;
    ssl_stapling on;
    ssl_stapling_verify on;

    # Add headers to serve security related headers
    # The always parameter ensures that the header is set for all responses, including internally generated error responses.
    # Before enabling Strict-Transport-Security headers please read into this topic first.
    # https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/

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

    # Path to the root of your installation
    root /var/www/owncloud/;

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

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

    # set max upload size
    client_max_body_size 512M;
    fastcgi_buffers 8 4K;                     # Please see note 1
    fastcgi_ignore_headers X-Accel-Buffering; # Please see note 2

    # Disable gzip to avoid the removal of the ETag header
    # Enabling gzip would also make your server vulnerable to BREACH
    # if no additional measures are done. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773332
    gzip off;

    # Uncomment if your server is build with the ngx_pagespeed module
    # This module is currently not supported.
    #pagespeed 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)/ {
        return 404;
    }
    location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
        return 404;
    }

    location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|oc[sm]-provider/.+||core/templates/40[34])\.php(?:$|/) {
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param SCRIPT_NAME $fastcgi_script_name; # necessary for ownCloud to detect the contextroot https://github.com/owncloud/core/blob/v10.0.0/lib/private/AppFramework/Http/Request.php#L603
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTPS on;
        fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
        fastcgi_param front_controller_active true;
        fastcgi_read_timeout 180; # increase default timeout e.g. for long running carddav/caldav syncs with 1000+ entries
        fastcgi_pass php-handler;
        fastcgi_intercept_errors on;
        fastcgi_request_buffering off; #Available since Nginx 1.7.11
    }

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

    # Adding the cache control header for js and css files
    # Make sure it is BELOW the PHP block
    location ~ \.(?:css|js)$ {
        try_files $uri /index.php$uri$is_args$args;
        add_header Cache-Control "max-age=15778463" always;

        # Add headers to serve security related headers (It is intended to have those duplicated to the ones above)
        # The always parameter ensures that the header is set for all responses, including internally generated error responses.
        # Before enabling Strict-Transport-Security headers please read into this topic first.
        # https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/

        #add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-XSS-Protection "1; mode=block" always;
        add_header X-Robots-Tag "none" always;
        add_header X-Download-Options "noopen" always;
        add_header X-Permitted-Cross-Domain-Policies "none" always;
        # Optional: Don't log access to assets
        access_log off;
    }

    location ~ \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg|map|json)$ {
        add_header Cache-Control "public, max-age=7200" always;
        try_files $uri /index.php$uri$is_args$args;
        # Optional: Don't log access to other assets
        access_log off;
    }
}

ownCloud in a subdirectory of Nginx

The following config should be used when ownCloud is placed under a different context root of your Nginx installation such as /owncloud or /cloud.

The configuration assumes that ownCloud is installed in /var/www/owncloud is accessed via http(s)://example.com/owncloud and that you have 'overwriteweb root' => '/owncloud', set in your config/config.php.

upstream php-handler {
    server 127.0.0.1:9000;
    #server unix:/var/run/php7.2-fpm.sock;
}

server {
    listen 80;
    listen [::]:80;
    server_name cloud.example.com;

    # For SSL certificate verification, this needs to be served via HTTP
    location /.well-known/(acme-challenge|pki-validation)/ {
        root /var/www/owncloud; # Specify here where the challenge file is placed
    }

    # enforce https
    location / {
        return 301 https://$server_name:443$request_uri; # Change 443 if using a custom HTTPS port
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name cloud.example.com;

    ssl_certificate /etc/ssl/nginx/cloud.example.com.crt;
    ssl_certificate_key /etc/ssl/nginx/cloud.example.com.key;

    # Example SSL/TLS configuration. Please read into the manual of Nginx before applying these.
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers "-ALL:EECDH+AES256:EDH+AES256:AES256-SHA:EECDH+AES:EDH+AES:!ADH:!NULL:!aNULL:!eNULL:!EXPORT:!LOW:!MD5:!3DES:!PSK:!SRP:!DSS:!AESGCM:!RC4";
    ssl_dhparam /etc/nginx/dh4096.pem;
    ssl_prefer_server_ciphers on;
    keepalive_timeout    70;
    ssl_stapling on;
    ssl_stapling_verify on;

    # Add headers to serve security related headers
    # The always parameter ensures that the header is set for all responses, including internally generated error responses.
    # Before enabling Strict-Transport-Security headers please read into this topic first.
    # https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/

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

    # Path to the root of your installation
    root /var/www/;

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

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

    location ^~ /owncloud {

        # set max upload size
        client_max_body_size 512M;
        fastcgi_buffers 8 4K;                     # Please see note 1
        fastcgi_ignore_headers X-Accel-Buffering; # Please see note 2

        # Disable gzip to avoid the removal of the ETag header
        # Enabling gzip would also make your server vulnerable to BREACH
        # if no additional measures are done. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773332
        gzip off;

        # Uncomment if your server is build with the ngx_pagespeed module
        # This module is currently not supported.
        #pagespeed off;

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

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

        location ~ ^/owncloud/(?:build|tests|config|lib|3rdparty|templates|data)/ {
            return 404;
        }
        location ~ ^/owncloud/(?:\.|autotest|occ|issue|indie|db_|console) {
            return 404;
        }

        location ~ ^/owncloud/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|oc[sm]-provider/.+|core/templates/40[34])\.php(?:$|/) {
            fastcgi_split_path_info ^(.+\.php)(/.*)$;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param SCRIPT_NAME $fastcgi_script_name; # necessary for ownCloud to detect the context root https://github.com/owncloud/core/blob/v10.0.0/lib/private/AppFramework/Http/Request.php#L603
            fastcgi_param PATH_INFO $fastcgi_path_info;
            fastcgi_param HTTPS on;
            fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
            # EXPERIMENTAL: active the following if you need to get rid of the 'index.php' in the URLs
            #fastcgi_param front_controller_active true;
            fastcgi_read_timeout 180; # increase default timeout e.g. for long running carddav/caldav syncs with 1000+ entries
            fastcgi_pass php-handler;
            fastcgi_intercept_errors on;
            fastcgi_request_buffering off; #Available since Nginx 1.7.11
        }

        location ~ ^/owncloud/(?:updater|oc[sm]-provider)(?:$|/) {
            try_files $uri $uri/ =404;
            index index.php;
        }

        # Adding the cache control header for js and css files
        # Make sure it is BELOW the PHP block
        location ~ /owncloud/.*\.(?:css|js) {
            try_files $uri /owncloud/index.php$uri$is_args$args;
            add_header Cache-Control "max-age=15778463" always;

            # Add headers to serve security related headers (It is intended to have those duplicated to the ones above)
            # The always parameter ensures that the header is set for all responses, including internally generated error responses.
            # Before enabling Strict-Transport-Security headers please read into this topic first.
            # https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/

            #add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload" always;
            add_header X-Content-Type-Options "nosniff" always;
            add_header X-Frame-Options "SAMEORIGIN" always;
            add_header X-XSS-Protection "1; mode=block" always;
            add_header X-Robots-Tag "none" always;
            add_header X-Download-Options "noopen" always;
            add_header X-Permitted-Cross-Domain-Policies "none" always;
            # Optional: Don't log access to assets
            access_log off;
        }

        location ~ /owncloud/.*\.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg|map|json) {
            try_files $uri /owncloud/index.php$uri$is_args$args;
            add_header Cache-Control "public, max-age=7200" always;
            # Optional: Don't log access to other assets
            access_log off;
        }
    }
}
1 Like

Setup Nginx wit Let’s Encrypt

Introduction

The following is an example setup process for Nginx, please adapt it to your exact needs.

Dependencies

To follow this guide, your server needs to have the following dependencies installed:

Assumptions

This guide assumes two things:

  • That you are using Ubuntu Linux 18.04. If you are not using Ubuntu 18.04, please adjust the instructions to suit your distribution or operating system.
  • That the Nginx server configuration file is stored under /etc/nginx/sites-available/ and is enabled. Not all distributions use this location, however. Please refer to your distribution’s Nginx documentation, to know where to store yours.

Create and Configure a Diffie-Hellman Params File

When using OpenSSL 1.0.2 or later you can generate and specify a Diffie-Hellman (DH) params file. If not already present, add an ssl_dhparam directive and a new certificate with stronger keys for Diffie-Hellman
based key exchange, which improves forward secrecy.

TIP: The OpenSSL command may take a quite a while to complete, so please be patient.

You can place the certificate into any directory you choose. However, in this guide we recommend /etc/nginx/, solely for the sake of simplicity.

sudo openssl dhparam -out /etc/nginx/dh4096.pem 4096

Add the following directive to your common SSL configuration:

ssl_dhparam /etc/nginx/dh4096.pem;

Let’s Encrypt ACME-Challenge

Add the /.well-known/acme-challenge location in your server directive for port 80

server {
  listen 80 ;
  server_name mydom.tld;
  location /.well-known/acme-challenge {
      default_type "text/plain";
      root /var/www/letsencrypt;
  }
  # ...
}

Create an SSL Server Configuration

We recommend creating a separate file for storing the SSL directives. If these directives already exist in this server block, delete them and include the file instead. When the certificate has been created, you can use this file in any SSL server block for which the certificate is valid without reissuing.

cd /etc/nginx/
sudo mkdir ssl_rules

Create a file named ssl_mydom.tld in the newly created directory.

# SSL rules for mydom.tld
# eases letsencrypt initial cert issuing
ssl on;
ssl_certificate         /etc/letsencrypt/live/mydom.tld/fullchain.pem;
ssl_certificate_key     /etc/letsencrypt/live/mydom.tld/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/mydom.tld/cert.pem;

TIP:

To improve SSL performance, we recommend that you use following directives.
Here’s an example configuration:

ssl_stapling on;
ssl_stapling_verify on;
ssl_session_timeout 5m;

Then adopt your server block:

server {
  listen 443 ssl http2;
  server_name mydom.tld;
  # ssl letsencrypt
  # include /etc/nginx/ssl_rules/ssl_mydom.tld;
  #...
}

IMPORTANT: For the moment, comment out the Include directive, as the certificate files do not, currently, exist.

Test and enable your Nginx configuration

To test your configuration run

sudo nginx -t

It should reply without errors.

Load your new Nginx configuration:

sudo service nginx reload

Create the SSL Certificates

Check that you have commented out the include directive as stated above and run the following command:

sudo /etc/letsencrypt/<your-domain-name>.sh

If successful, you will see output similar to that below, when the command completes:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: Y
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for mydom.tld
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Running post-hook command: service nginx reload
IMPORTANT NOTES:
 1. Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/mydom.tld/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/mydom.tld/privkey.pem
    Your cert will expire on 2018-06-18. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew *all* of your certificates, run
    "certbot renew"
 2. Your account credentials have been saved in your Certbot
    configuration directory at /etc/letsencrypt. You should make a
    secure backup of this folder now. This configuration directory will
    also contain certificates and private keys obtained by Certbot so
    making regular backups of this folder is ideal.
 3. If you like Certbot, please consider supporting our work by:
    Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
    Donating to EFF:                    https://eff.org/donate-le

To double check the issued certificate, run the list.sh script as follows.

sudo /etc/letsencrypt/list.sh

If successful, you should see output similar to the following:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Found the following certs:
  Certificate Name: mydom.tld
    Domains: mydom.tld
    Expiry Date: 2018-06-18 13:20:34+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/mydom.tld/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/mydom.tld/privkey.pem
-------------------------------------------------------------------------------

As the SSL certificate has been successfully issued by Let’s Encrypt, you can un-comment the include directive for your domain’s SSL rules, in the server block configuration.

server {
  listen 443 ssl http2 ;
  server_name mydom.tld;
  # ssl letsencrypt
  include /etc/nginx/ssl_rules/ssl_mydom.tld;
  #...
}

Reload the Nginx configuration

sudo service nginx reload

Your web server is now ready to serve https request for the given domain using the issued certificates.

1 Like

Big File Upload Configuration (> 512MB)

General configuration

See https://doc.owncloud.org/server/10.3/admin_manual/configuration/files/big_file_upload_configuration.html in the official documentation or How to change upload limits and fix upload problems for an older FAQ at this forums.

Nginx specific configuration

Since Nginx 1.7.11 a new config option fastcgi_request_buffering is availabe. Setting this option to fastcgi_request_buffering off; in your Nginx config might help with timeouts during the upload.
Furthermore it helps if you’re running out of disc space on the /tmp partition of your system.

For more info how to configure Nginx to raise the upload limits see also this wiki entry.

TIP: Make sure that client_body_temp_path points to a partition with adequate space for your upload file size, and on the same partition as the upload_tmp_dir or tempdirectory (see below). For optimal performance, place these on a separate hard drive that is dedicated to swap and temp storage.

If your site is behind a Nginx frontend (for example a loadbalancer):

By default, downloads will be limited to 1GB due to proxy_buffering and proxy_max_temp_file_size on the frontend.

1 Like

Troubleshooting

General Troubleshooting

See https://doc.owncloud.org/server/10.3/admin_manual/configuration/general_topics/general_troubleshooting.html

OAuth2 ownCloud clients cannot connect to the ownCloud server

If ownCloud clients cannot connect to your ownCloud server, check to see if PROPFIND requests receive HTTP/1.1 401 Unauthorized responses. If this is happening, more than likely your webserver configuration is stripping out the bearer authorization header.

Add the following configuration to your Nginx setup:

# Adding this allows the variable to be accessed with $_SERVER['Authorization']
fastcgi_param Authorization $http_authorization;

Problematic Web Server and PHP Modules

There are some Web server and PHP modules which are known to cause various problems like broken up-/downloads. The following shows a draft overview of these modules:

PHP

https://doc.owncloud.org/server/10.3/admin_manual/configuration/general_topics/general_troubleshooting.html#php

Nginx

  • ngx_pagespeed
  • HttpDavModule
  • X-Sendfile (causing broken downloads if not configured correctly)

JavaScript (.js) or CSS (.css) files not served properly

A standard issue with custom Nginx configurations is, that JavaScript (.js) or CSS (.css) files are not served properly, leading to a 404 (File Not Found) error on those files and a broken web interface.

This could be caused by an inproper sequence of location blocks. The following sequence is correct:

  location ~ \.php(?:$|/) {
   ...
  }
  location ~ \.(?:css|js)$ {
   ...
  }

Other custom configurations like caching JavaScript (.js) or CSS (.css) files via gzip could also cause such issues.

Not all of my contacts are synchronized

Check for server timeouts! It turns out that CardDAV sync often fails silently if the request runs into timeouts. With PHP-FPM you might see a CoreDAVHTTPStatusErrorDomain error 504 which is an HTTP 504 Gateway timeout error. To solve this, first check the default_socket_timeout setting in /etc/php/7.0/fpm/php.ini and increase the above fastcgi_read_timeout accordingly. Depending on your server’s performance a timeout of 180s should be sufficient to sync an address book of ~1000 contacts.

Windows: Error 0x80070043 “The network name cannot be found.” while adding a network drive

The windows native WebDAV client might fail with the following error message:

Error 0x80070043 "The network name cannot be found." while adding a network drive

A known workaround for this issue is to update your web server configuration.

1. Create a map directive outside your server block

# Fixes Windows WebDav client error 0x80070043 "The network name cannot be found."
map "$http_user_agent:$request_method" $WinWebDav {
    default         0;
    "DavClnt:OPTIONS"   1;
}

2. Inside your server block on top of your location directives

location = / {
    if ($WinWebDav) { return 401; }
}
1 Like

Log Optimisation

Suppressing htaccesstest.txt and .ocdata Log Messages

If you are seeing meaningless messages in your logfile, for example Htaccesstest.txt errors in logfiles, or access to .ocdata, add this section to your Nginx configuration to suppress them:

location = /data/htaccesstest.txt {
    allow all;
    log_not_found off;
    access_log off;
}
location = /data/\.ocdata {
    access_log off;
}

Prevent access log entries when accessing thumbnails

When using eg. the Gallery App, any access to a thumbnail of a picture will be logged. This can cause a massive log quanity making log reading challenging. With this approach, you can prevent access logging for those thumbnails.

1. Create a map directive outside your server block like

(Adopt the path queried according your needs.)

# do not access log to gallery thumbnails, flooding access logs only, error will be logged anyway
map $request_uri $loggable {
    default                              1;
    ~*\/apps\/gallery\/thumbnails        0;
}

2. Inside your server block where you define your logs

access_log /path-to-your-log-file combined if=$loggable;

If you want or need to log thumbnails access, you can easily add another logfile which only logs this access. You can easily enable / disable this kind of logging if you uncomment / comment the line starting with 0 in the following map directive.

Below the above map statement

# invert the $loggable variable
map $loggable $invertloggable {
    default                         0;
    0                               1;
}

Below the above access_log statement

access_log /var/log/nginx/<your-log-file-inverted> combined if=$invertloggable;
1 Like

Performance Tuning

1. HTTP/2

To increase the performance of your Nginx installation, we recommend using either the SPDY or HTTP_V2 modules, depending on your installed Nginx version.

To use HTTP_V2 for Nginx you have to check two things:

  1. Be aware that this module may not built in by default, due to a dependency to the OpenSSL version used on your system. It will be enabled with the --with-http_v2_module configuration parameter during compilation. The dependencies should be checked automatically. You can check the presence of ngx_http_v2_module by using the command: nginx -V 2>&1 | grep http_v2 -o. A description of how to compile Nginx to include modules can be found in Compiling Modules.
  2. When changing from SPDY to HTTP v2, the Nginx config has to be changed from listen 443 ssl spdy; to listen 443 ssl http2;

2. Caching Metadata

The open_file_cache directive can help you to cache file metadata information. This can increase performance on high loads respectively when using eg NFS as backend. That cache can store:

  • Open file descriptors, their sizes and modification times;
  • Information on existence of directories;
  • File lookup errors, such as “file not found”, “no read permission”, and so on.

To configure metadata caching, add following directives either in your http, server or location block:

open_file_cache                 max=10000 inactive=5m;
open_file_cache_valid           1m;
open_file_cache_min_uses        1;
open_file_cache_errors          on;

Configure Nginx to use caching for ownCloud internal images and thumbnails

This mechanism speeds up presentation as it shifts requests to Nginx and minimizes PHP invocations, which otherwise would take place for every thumbnail or internal image presented every time.

1. Preparation

  • Create a directory where Nginx will save the cached thumbnails or internal images. Use any path that fits to your environment. Replace /opt/cachezone in this example with your path created:
sudo mkdir -p /opt/cachezone
sudo chown www-data:www-data /opt/cachezone

2. Configuration

a. Define when to skip the cache:

  • Option 1: map

This is the preferred method. In the http{} block, but outside the server{} block:

# skip_cache, default skip
map $request_uri $skip_cache {
     default              1;
     ~*\/thumbnail.php    0;
     ~*\/apps\/gallery\/  0;
     ~*\/core\/img\/      0;
}
  • Option 2: if

In the server{} block, above the location block mentioned below:

set $skip_cache 1;
if ($request_uri ~* "thumbnail.php")      { set $skip_cache 0; }
if ($request_uri ~* "/apps/gallery/")     { set $skip_cache 0; }
if ($request_uri ~* "/core/img/")         { set $skip_cache 0; }

a. General Config:

In case you want to have multiple cache paths with different cache keys, follow the Nginx documentation where to place the directives. For the sake of simplicity, we both add them to the http{} block.

  • Add inside the http{} block:
fastcgi_cache_path /opt/cache levels=1:2 keys_zone=cachezone:100m
                   max_size=500m inactive=60m use_temp_path=off;
fastcgi_cache_key $http_cookie$request_method$host$request_uri;
  • Add inside the server{} block the following FastCGI caching directives, as an example of a configuration:
location ~ \.php(?:$/) {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi_params;
    # ...
    ## Begin - FastCGI caching
    fastcgi_ignore_headers  "Cache-Control"
                            "Expires"
                            "Set-Cookie";
    fastcgi_cache_use_stale error
                            timeout
                            updating
                            http_429
                            http_500
                            http_503;
    fastcgi_cache_background_update on;
    fastcgi_no_cache $skip_cache;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_cache cachezone;
    fastcgi_cache_valid  60m;
    fastcgi_cache_methods GET HEAD;
    ## End - FastCGI caching
}

3 Test the configuration

sudo nginx -t
sudo service nginx reload
  • Open your browser and clear your cache.
  • Logon to your ownCloud instance, open the gallery app, move thru your folders and watch while the thumbnails are generated for the first time.
  • You may also watch with eg. htop your system load while the thumbnails are processed.
  • Go to another app or logout and relogon.
  • Open the gallery app again and browse to the folders you accessed before. Your thumbnails should appear more or less immediately.
  • htop will not show up additional load while processing, compared to the high load before.
1 Like

1. preserved for additional content

2. preserved for additional content

3. preserved for additional content

I’m not sure about the following optional Nginx configuration of https://central.owncloud.org/t/unofficial-community-nginx-documentation/22365/6:

When adding this code to my Nginx configuration i’m getting the following message in my admin backend:

Your data directory and your files are probably accessible from the Internet. The .htaccess file is not working. We strongly suggest that you configure your web server in a way that the data directory is no longer accessible or you move the data directory outside the web server document root.

2 Likes

moved to FAQ category for people to better find it. Thanks for doing this.

2 Likes