I've been trying to get my server up and running but the WebDAV side of things is killing me. Cozy and ArkOS are still far and away, so yeah. For the most part it is setup, but again. WebDAV and sync. Just ugh. I have a post up on OwnCloud's forums but haven't heard anything in a few days, so now just throwing scattering shit out everywhere to see if I can get help from somewhere else.

Spoilered For Length ( xpost from OwnCloud forum post ) :

Spoiler: show

Okay, so I'm unable to figure out what is causing this problem or how to fix it. DDG searches provided no assistance in the matter and browsing around the forums only show a single page of threads with similar situations / material that don't fix my issues.


I'm using the latest version of OwnCloud, loaded onto an Ubuntu 12.04 LTS LXC. The host system uses Nginx as a reverse proxy. Another LXC on the host system serves DNS for web addresses. Yet another container on the system serves MySQL databases. This host system sits behind a pfSense firewall box ( a separate piece of hardware upstream of this LXC host system ). The pfSense box provides the network addresses for all hardware, including the addresses of the various LXCs via DHCP ( MAC addresses used to assign ) and DNSMASQ. The addresses of virtual hosts are provided by the Bind9 DNS. Bind9 DNS resolution occurs because the DNSMASQ on the pfSense box is setup to override for the domain name, so that the Bind9 LXC is queried prior to DNSMASQ.

The Nginx reverse proxy in this case serves only as a pointer; ie, ports 80 and 443 are forwarded through the pfSense box to the LXC host, and because the host has the Nginx setup it then redirects traffic as necessary to the LXCs.

The setup on the Nginx proxy for this particular virtual host ( there are many others, mainly admin tools like postfixadmin and phpmyadmin and base and webmin etc that I am using Nginx to redirect to so I don't have to remember port numbers or type long addresses in ) looks like this:
Code:
server {
    listen 80;
    listen 443 default_server ssl;
    ## Separate entries for listen directives are not needed here because
    #  the container is dedicated to just cloud, and the Apache2 server
    #  will redirect any traffic to SSL.
    server_name -edited out because forum spam rules don't allow addresses-;

    access_log /var/log/nginx/cloud_access.log;
    error_log /var/log/nginx/cloud_error.log;
    root /usr/share/nginx/www;
    index index.html index.htm;

    client_max_body_size 16G;

    if ($scheme = http) {
             return 301 https://$server_name$request_uri;
        }
    
    location / {
        proxy_pass https://192.168.4.100;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_redirect default;
        proxy_buffering off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
The setup on the LXC running ownCloud ( Apache2 ):
Code:
<VirtualHost *:80>
        RewriteEngine on
        ReWriteCond %{SERVER_PORT} !^443$
        RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
   ServerAdmin -edited out because forum spam rules don't allow addresses-
   DocumentRoot /var/www
   <Directory />
      Options FollowSymLinks
      AllowOverride All
   </Directory>
   ErrorLog ${APACHE_LOG_DIR}/error.log
   # Possible values include: debug, info, notice, warn, error, 
   # crit, alert, emerg.
   LogLevel warn
   CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
   #   SSL Engine Switch: Enable/Disable SSL for this virtual host.
   SSLEngine on
   #   A self-signed (snakeoil) certificate can be created by 
   #   installing the ssl-cert package. See 
   #   /usr/share/doc/apache2.2-common/README.Debian.gz for more 
   #   info. If both key and certificate are stored in the same 
   #   file, only the SSLCertificateFile directive is needed.
   SSLCertificateFile /etc/ssl/certs/Wildcard+Server+Certificate.crt
   SSLCertificateKeyFile /etc/ssl/private/Wildcard+Server+Certificate.key
   #   Server Certificate Chain: Point SSLCertificateChainFile at a 
   #file containing the concatenation of PEM encoded CA 
   #certificates which form the certificate chain for the server 
   #certificate. Alternatively the referenced file can be the same 
   #as SSLCertificateFile when the CA certificates are directly 
   #appended to the server certificate for convinience. 
   #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
   #   Certificate Authority (CA): Set the CA certificate 
   #   verification path where to find CA certificates for client 
   #   authentication or alternatively one huge file containing all 
   #   of them (file must be PEM encoded) Note: Inside 
   #   SSLCACertificatePath you need hash symlinks
   #         to point to the certificate files. Use the provided 
   #Makefile to update the hash symlinks after changes. 
   #SSLCACertificatePath /etc/ssl/certs/ SSLCACertificateFile 
   #/etc/apache2/ssl.crt/ca-bundle.crt
   #   Certificate Revocation Lists (CRL): Set the CA revocation 
   #   path where to find CA CRLs for client authentication or 
   #   alternatively one huge file containing all of them (file 
   #   must be PEM encoded) Note: Inside SSLCARevocationPath you 
   #   need hash symlinks
   #         to point to the certificate files. Use the provided 
   #Makefile to update the hash symlinks after changes. 
   #SSLCARevocationPath /etc/apache2/ssl.crl/ SSLCARevocationFile 
   #/etc/apache2/ssl.crl/ca-bundle.crl
   #   Client Authentication (Type): Client certificate 
   #verification type and depth.  Types are none, optional, require 
   #and optional_no_ca.  Depth is a number which specifies how 
   #deeply to verify the certificate issuer chain before deciding 
   #the certificate is not valid. SSLVerifyClient require 
   #SSLVerifyDepth 10
   #   Access Control: With SSLRequire you can do per-directory 
   #access control based on arbitrary complex boolean expressions 
   #containing server variable checks and other lookup directives.  
   #The syntax is a mixture between C and Perl.  See the mod_ssl 
   #documentation for more details. <Location /> SSLRequire ( 
   #%{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
   #            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ and 
   #           %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ 
   #           and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ and 
   #           %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ or 
   #           %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ 
   #           </Location> SSL Engine Options: Set various options 
   #           for the SSL engine. o FakeBasicAuth: Translate the 
   #           client X.509 into a Basic Authorisation.  This means 
   #           that the standard Auth/DBMAuth methods can be used 
   #           for access control.  The user name is the `one line' 
   #           version of the client's X.509 certificate. Note that 
   #           no password is obtained from the user. Every entry 
   #           in the user file needs this password: 
   #           `xxj31ZMTZzkVA'. o ExportCertData: This exports two 
   #           additional environment variables: SSL_CLIENT_CERT 
   #           and SSL_SERVER_CERT. These contain the PEM-encoded 
   #           certificates of the server (always existing) and the 
   #           client (only existing when client authentication is 
   #           used). This can be used to import the certificates 
   #           into CGI scripts. o StdEnvVars: This exports the 
   #           standard SSL/TLS related `SSL_*' environment 
   #           variables. Per default this exportation is switched 
   #           off for performance reasons, because the extraction 
   #           step is an expensive operation and is usually 
   #           useless for serving static content. So one usually 
   #           enables the exportation for CGI and SSI requests 
   #           only. o StrictRequire: This denies access when 
   #           "SSLRequireSSL" or "SSLRequire" applied even under a 
   #           "Satisfy any" situation, i.e. when it applies access 
   #           is denied and no other module can change it. o 
   #           OptRenegotiate: This enables optimized SSL 
   #           connection renegotiation handling when SSL 
   #           directives are used in per-directory context. 
   #           SSLOptions +FakeBasicAuth +ExportCertData 
   #           +StrictRequire
   <FilesMatch "\.(cgi|shtml|phtml|php)$">
      SSLOptions +StdEnvVars
   </FilesMatch>
   <Directory /usr/lib/cgi-bin>
      SSLOptions +StdEnvVars
   </Directory>
   #   SSL Protocol Adjustments: The safe and default but still 
   #   SSL/TLS standard compliant shutdown approach is that mod_ssl 
   #   sends the close notify alert but doesn't wait for the close 
   #   notify alert from client. When you need a different shutdown 
   #   approach you can use one of the following variables: o 
   #   ssl-unclean-shutdown:
   #     This forces an unclean shutdown when the connection is 
   #   closed, i.e. no SSL close notify alert is send or allowed to 
   #   received.  This violates the SSL/TLS standard but is needed 
   #   for some brain-dead browsers. Use this when you receive I/O 
   #   errors because of the standard approach where mod_ssl sends 
   #   the close notify alert. o ssl-accurate-shutdown:
   #     This forces an accurate shutdown when the connection is 
   #   closed, i.e. a SSL close notify alert is send and mod_ssl 
   #   waits for the close notify alert of the client. This is 100% 
   #   SSL/TLS standard compliant, but in practice often causes 
   #   hanging connections with brain-dead browsers. Use this only 
   #   for browsers where you know that their SSL implementation 
   #   works correctly. Notice: Most problems of broken clients are 
   #   also related to the HTTP keep-alive facility, so you usually 
   #   additionally want to disable keep-alive for those clients, 
   #   too. Use variable "nokeepalive" for this. Similarly, one has 
   #   to force some clients to use HTTP/1.0 to workaround their 
   #   broken HTTP/1.1 implementation. Use variables 
   #   "downgrade-1.0" and "force-response-1.0" for this.
   BrowserMatch "MSIE [2-6]" \
      nokeepalive ssl-unclean-shutdown \
      downgrade-1.0 force-response-1.0
   # MSIE 7 and newer should be able to use keepalive
   BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
</IfModule>
PHP5 *.ini configuration:
Code:
...
; Maximum size of POST data that PHP will accept.
; http://php.net/post-max-size
post_max_size = 16G
...
; Whether to allow HTTP file uploads.
; http://php.net/file-uploads
file_uploads = On

; Temporary directory for HTTP uploaded files (will use system default if not
; specified).
; http://php.net/upload-tmp-dir
;upload_tmp_dir =

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 16G

; Maximum number of files that can be uploaded via a single request
max_file_uploads = 250000
...
output_buffering = 16384
If you're balking at these numbers, please understand I originally started with production default values. I have raised them to this point out of desperation in getting things to work. It seemed to help to some degree ( it takes a few hours now to encounter the problem again ), but the returns are diminishing and these numbers are already stupid high. I apologise if this is confusing, but if it were simple I wouldn't be here for the help.

The system appears to be working fine from web side, and I am able to access both ownCloud and WebDAV ( using the manual address provided by other forum threads ) from behind my pfSense firewall and from my work computers ( separate, external network ). I can upload, download, and delete files from the web interface without issue ( initially had some issues with default production settings in Apache and PHP because of file limits / body sizes above ). Using the ownCloud sync client 1.5.0 ( build 1913 ) on my Windows 8.1 systems I am trying to Sync up my data folders. After several hours of successful uploads, the data transfer will begin to fail. The only error provided is in the ownCloud sync client ( which appears as noted in Thread Title ), there are no error messages on the Nginx or Apache servers. I am sure now the failure does not relate to size uploaded, because on some uploads I could do several GB of data and on others I can only do a few hundred MB before the Insufficient Storage errors occur. My gut tells me it's a file number problem, but I have no justification for that - the number of files to upload in my last attempt was only 40k ( so less than the 250k limit ) and it failed at around 16 or 17k uploaded.

*RIGHT* before the Insufficient Storage error occurs, I lose the ability to see storage used. On the ownCloud client in the bottom corner is the "Storage Usage" box. Normally it shows a bar with data used ( I have currently put a cap on my account of 50GB, even though the server has a terabyte available. Part of testing. ) but just before the Insufficient Storage errors begin occurring this bar vanishes and is replaced with a message "Currently there is no storage usage information available". Immediately following the display of this message the sync operation appears to speed up dramatically, and viewing the "Activity" tab shows that every file attempted to upload displays a "Insufficient Storage" message, even though several GB remain on the quota. This will continue until it reaches the end of the queued upload, during which the client becomes unresponsive. Once it reaches the end of the queue, the client becomes accessible again, but no longer functions. The client still says it is connected, but the X icon appears over the cloud and no further sync operations will occur until I close down the client, reboot the server, and reopen the client.


As noted above, I attempted to correct these errors by boosting the allowed limits in Nginx, Apache, and PHP. The current limits of 16GB are ridiculously large, and given no errors appear in the Nginx or Apache logs I cannot see how / if this is a server configuration issue. I have additionally utilised this tool (link) just for shits and giggles, but it finds no problems with my setup. Version notes are provided in this post and in my profile. I have tested with Mozilla and IE.


Edit; Fixed some grammar. But another note - if you right click on the ownCloud client, it shows a message "0% of -1B in use" which I found some mention of in other threads but nothing to yet fix my problem.

PS: From the OC forums, my versions:

ownCloud version: 6.0.0a
Webserver: Apache
Database: MySQL
OS: Linux
PHP version: 5.3.10-1ubuntu3.9




On a more general note, I'm also having issues mounting the WebDAV in OwnCloud on my Windows machines. I can point at the remote directory and login / browse without issue using IE or FF, but Windows keeps telling me that the address I'm pointing to is no good.