[webdav] Fout: X-OC-MTime header must be a valid positive integer

Hi everyone,

Im new here and would like to ask a question about an error when trying to upload a photo using the memories app.
When selecting a photo in the app and try to send it to my nextcloud server the following error message Spears in the log file:

[webdav] Fout: X-OC-MTime header must be a valid positive integer

Is anyone familiar with this error?

Regards, Harry

I had the same issue uploading large files from Android web browsers via share link, the solution I found for my setup (NGINX reverse proxy) was to replace the negative X-OC-MTime header value sent by the web client with the current time.

I added a map in nginx.conf to replace negative values of X-OC-MTime:

map $http_x_oc_mtime $xocmtimefix {
      "~^-\d+" "$msec";
      default $http_x_oc_mtime;
    }

And I used that map on the default.conf reverse proxy setup:

proxy_set_header X-OC-MTime $xocmtimefix;

This is a workaround to the web clients sending an invalid X-OC-MTime value.

Thanx for your feedback, i’ll give it a try. For now I use npm. But I think i can make the same configuration you do.

I’ll let you know what the outcome i

hi i could use some help on implementing your workaroud
not sure where to place all that…

is this all located in the nextcloud cfg file of nginx?

Hi zeitlins,

My fix is done in NGINX, first you have to create a new variable that will be the value of $http_x_oc_mtime only if it’s valid, else it will be the current time.

Here’s my /etc/nginx/nginx.conf file (where the variable is defined):

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" "$http_x_oc_mtime"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    map $http_x_oc_mtime $xocmtimefix { # <-- the new variable
      "~^-\d+" "$msec";
      default $http_x_oc_mtime;
    } # <------------------------------------ the new variable

    include /etc/nginx/conf.d/*.conf;
}

Once you modify your nginx.conf you’ll have to restart your NGINX for the variable to be available to be used. Once you have done that, here’s the usage of the variable itself in a *.conf file, in my case I have Nextcloud under the mysite.com/nextcloud path, but it should be the same on the root path if that’s your case:

location /nextcloud/ {
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-OC-MTime $xocmtimefix; # <-- using the new variable to override  X-OC-MTime
    add_header Front-End-Https on;

    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 64;

    proxy_buffering off;
    proxy_redirect off;
    proxy_max_temp_file_size 0;
    proxy_connect_timeout 1000;
    proxy_send_timeout 1000;
    proxy_read_timeout 1000;
    send_timeout 1000;
    proxy_pass http://<your-upstream-nginx>/;
  }

Once you modify your *.conf file (e.g. default.conf, mysite.conf) you just have to reload NGINX.
Check for <-- in the code examples to get what you have to copy/paste into your NGINX reverse proxy setup.

I did some research and noticed that the timzone in the nextcloud containers is utc. Thats not the zone I live in. I read that the nextcloud containers use their own timezone. I tried to modify it in truenas but its not allowed.

I continu my search for a proper solution, but I like to share this info with you guys.

Have a nice day

now i get you so i´ll need a reverse proxy :slight_smile: … i´ll have to dig that or is there a way without reverse proxy