• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue Filesharing randomly dropping lager files

DReffects

Basic Pleskian
Hey Guys,

I am having a bit of an issue with the plesk webdav filesharing thingy. While uploading, the system more or less randomly drops larger files down to zero bytes.

I am using CentOS 7 with nginx php7 - unfortunately I am unable to find any information in the logs.

Wheren can I
- set the maximum upload size?
- see errors?

thanks :)
 
Hi DReffects,

filesharing ( webdav ) is done over the Plesk Control Panel, so the corresponding log - file ist the panel.log at "/var/log/plesk"


Sometimes, it is as well a good idea to change the log - level ( TEMPORARILY! ), to get more informations in Plesk - log - files:


If you would like to raise current PHP - settings for your Plesk Control Panel, you'll have to edit the file "/usr/local/psa/admin/conf/php.ini"
 
Hi UFHH01,

thanks for your response!
panel.log does not report anything unusual - infact, there's nothing else in there besides the usual "failed login attempt" messages.

Strangely enough uploading larger files via the plesk website works every time. Using the webdav-url with windows or software like expandrive fails though.

Will events still being logged within panel.log when using the WebDAV URL?
I am quite unsure about the whole log situation since the server supports three php versions.

access.log within the /var/vhost/domain.com/logs directory contains the whole webdav connections - error.log in the same path does not contain any errors.

I'd like to transfer files up to 2GB of size - what parameters need to be modified for this?
Can this be releated to a maximum input time value or apache upload limit? If so, why isn't this being reported in the error.log?

Thanks :)

PS: Grüße nach Hamburg! :)
 
Hi DReffects,

if you transfer over your WebDAV - URL, you will certainly see your domain - specific log - files in case of issues/errors/problems and you have to edit domain - specific PHP - settings.

Here's a schemata of the PHP versions in charge ( for your domains ):

Plesk-Onyx_PHP-schemata.png
Each PHP - version depends on the previous one and therefore inherits the previous settings, if they haven't been explicitly changed in the next PHP - version. ;)
 
Hi @UFHH01,

thanks for the in-depth explanation. Makes the troubleshooting way more easy!
I cannot find any errors within the hosts log files or anywhere else - some transfers simply produce a 0 byte file on the server.
Unfortunately, this behaviour is not consistent. Transfering the same file over and over results in a 0 byte file 5 out of 10 times.

Do you have any experience in relation to this and the nginx reverse proxy? I've disabled intelligent file handling for the moment and doing some tests.

Cheers
 
Hi DReffects,

Do you have any experience in relation to this and the nginx reverse proxy? I've disabled intelligent file handling for the moment and doing some tests.
Unfortunately, I never did some tests here... but since you are having some issues... I'm trying to write that on my "to-do - list". :)
 
I've set the loglevel to E_ALL but it still remains inconclusive.

During the upload transfer speed is as it should be. Right after the upload's finished i get an 401 error.
2017-04-13 23:04:24 Access 123.123.123.200 201 PUT /fileserver/private/test/_test%20gro%C3%9Fe%20Datei/256MB HTTP/1.0 657 Apache-Zugriff
2017-04-13 23:04:24 Access 123.123.123.200 207 PROPFIND /fileserver/private/test/_test%20gro%C3%9Fe%20Datei/256MB HTTP/1.0 1.24 K Apache-Zugriff
2017-04-13 23:10:32 Error 123.123.123.200 401 PUT /fileserver/private/test/_test%20gro%C3%9Fe%20Datei/256MB HTTP/1.0 1.69 K Apache-Zugriff
2017-04-13 23:10:33 Access 123.123.123.200 204 PUT /fileserver/private/test/_test%20gro%C3%9Fe%20Datei/256MB HTTP/1.0 259 Apache-Zugriff
The sequence is concluded but another PUT request.

Any ideas you might have is highly appreciated! :)
 
Hi
@UFHH01

I did some testing last night. Turns out file size does not matter - what matters is how long the transfer takes.
Everything below aprox. 250 seconds is fine, everything above that produces a zero byte filesize.

I've already set for php:
max_execution_time = 6000
max_input_time = 6000


as well as for the nginx configuration:
client_header_timeout 360m;
client_body_timeout 360m;
send_timeout 360m;
fastcgi_read_timeout 6000;

PHP7 is running as a "FPM-Application with Apache" ("FPM-Anwendung durch Apache bedient")

Can you please help me out here? :)
 
Hi DReffects,

first, pls. consider to add ( temporarily !!! ) as "Additional directives for HTTP" and "Additional directives for HTTPS" ( HOME > Subscriptions > YOUR-DOMAIN.COM > Apache & nginx Settings ):
Code:
LogLevel debug
For nginx, you could add at "Additional nginx directives" :
Code:
access_log "/var/www/vhosts/system/YOUR-DOMAIN.COM/logs/proxy_access_ssl_log" debug;
error_log "/var/www/vhosts/system/YOUR-DOMAIN.COM/logs/proxy_error_log" debug;


If you changed PHP - settings and nginx settings, pls. always include, WHERE you changed the setting, so people willing to help you are able to reproduce that.
Now that you changed the log - level to "debug", pls. repeat your upload - process and investigate the corresponding logs for issues/errors/problems. Post the corresponding entries if you need help with the investigations.
 
Hi @UFHH01

thanks for the guidance!

The mentioned PHP and nginx settings have been set on the plesk hosting settings page. I've moved on to editing the vhost.conf file itself for the time being:

Code:
<------>location ~ ^/fileserver/ {
<------><------>proxy_pass https://xxxxxxxx:7081;
<------><------>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-Accel-Internal /internal-nginx-static-location;
<------><------>#access_log off;
<------><------>access_log /tmp/nginx.log;
<------><------>error_log /tmp/nginx.error.log debug;
<------><------>#client_header_timeout 360m; #set on a global level
<------><------>client_body_timeout 360m;
<------><------>send_timeout 360m;
<------><------>fastcgi_read_timeout 6000;
<------><------>#client_body_buffer_size 1000M; #tried that, didn't change the issues
<------><------>chunked_transfer_encoding off; #tried that, didn't change the issues
<------><------>client_body_in_file_only on;


Unfortunately access_log level debug isn't available for nginx, the debug error log does not report anything out of the ordinary.
The only messages I get in the error log is
Code:
2017/04/14 15:34:19 [notice] 25380#0: *1751 a client request body is buffered to a temporary file /var/lib/nginx/body/0000000082, cl

Here's a full log set from the nginx access log:
Code:
123.123.123.123 - - [14/Apr/2017:15:21:16 +0200] "PUT /fileserver/private/testing/256MB HTTP/1.1" 401 1273 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:21:16 +0200] "PUT /fileserver/private/testing/256MB HTTP/1.1" 204 0 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:21:16 +0200] "PROPPATCH /fileserver/private/testing/256MB HTTP/1.1" 207 289 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:21:46 +0200] "PROPFIND /fileserver/private/testing/ HTTP/1.1" 207 9717 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:25:47 +0200] "PROPFIND /fileserver/private/testing/ HTTP/1.1" 207 9697 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:26:24 +0200] "PROPFIND /fileserver/private/testing/ HTTP/1.1" 401 1273 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:26:24 +0200] "PROPFIND /fileserver/private/testing/ HTTP/1.1" 207 9697 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:26:26 +0200] "PROPPATCH /fileserver/private/testing/256MB HTTP/1.1" 207 289 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:26:26 +0200] "PROPFIND /fileserver/private/testing/256MB HTTP/1.1" 207 1003 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:32:39 +0200] "PUT /fileserver/private/testing/256MB HTTP/1.1" 401 1273 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:32:39 +0200] "PUT /fileserver/private/testing/256MB HTTP/1.1" 204 0 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:32:39 +0200] "PROPPATCH /fileserver/private/testing/256MB HTTP/1.1" 207 289 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:15:34:19 +0200] "PROPFIND /fileserver/private/testing/ HTTP/1.1" 207 9697 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:20:19:39 +0200] "PROPFIND /fileserver/private/testing/ HTTP/1.1" 401 1273 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"
123.123.123.123 - - [14/Apr/2017:20:19:39 +0200] "PROPFIND /fileserver/private/testing/ HTTP/1.1" 207 9697 "-" "Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)"

.... continued in next post due to 1000 character limit...
 
...continuing:


I've set
Code:
client_body_in_file_only on;
and checked if nginx is recieving the file correctly. The whole file is being saved to the temp folder - so for some reason the problem seems to be when nginx is trying to write the file to it's new location.

as you can see above, nginx access_log gets response code 401 and then proceeds to set the file size to zero. I've narrowed it down to aprox. 240-260 seconds. every upload longer that that produces the error. file size does not matter, just how long it takes.

And finally here's the whole thing from the apache logs' side of view:

Code:
2017-04-14 20:36:50    Access    123.123.123.123    207    PROPPATCH /fileserver/private/test/256MB HTTP/1.0        Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)    811     SSL/TLS-Zugriff für Apache
2017-04-14 20:36:50    Access    123.123.123.123    207    PROPFIND /fileserver/private/test/256MB HTTP/1.0        Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)    1.49 K    SSL/TLS-Zugriff für Apache
2017-04-14 20:36:50    Error    123.123.123.123        [ssl:debug] ssl_engine_kernel.c(224): AH02034: Initial (No.1) HTTPS request received for child 81 (server test.com:443)                Apache-Fehler
2017-04-14 20:36:50    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of Require user "test" "admin": denied (no authenticated user yet)                Apache-Fehler
2017-04-14 20:36:50    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)                Apache-Fehler
2017-04-14 20:36:50    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of Require user "test" "admin": granted                Apache-Fehler
2017-04-14 20:36:50    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: granted                Apache-Fehler
2017-04-14 20:36:50    Error            [headers:debug] mod_headers.c(823): AH01502: headers: ap_headers_output_filter()                Apache-Fehler
2017-04-14 20:36:50    Error    123.123.123.123        [ssl:debug] ssl_engine_kernel.c(224): AH02034: Initial (No.1) HTTPS request received for child 83 (server test.com:443)                Apache-Fehler
2017-04-14 20:36:50    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of Require user "test" "admin": denied (no authenticated user yet)                Apache-Fehler
2017-04-14 20:36:50    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)                Apache-Fehler
2017-04-14 20:36:50    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of Require user "test" "admin": granted                Apache-Fehler
2017-04-14 20:36:50    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: granted                Apache-Fehler
2017-04-14 20:36:50    Error            [headers:debug] mod_headers.c(823): AH01502: headers: ap_headers_output_filter()                Apache-Fehler
2017-04-14 20:43:07    Error    123.123.123.123    401    PUT /fileserver/private/test/256MB HTTP/1.0        Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)    1.89 K    SSL/TLS-Zugriff für Apache
2017-04-14 20:43:07    Error    123.123.123.123        [ssl:debug] ssl_engine_kernel.c(224): AH02034: Initial (No.1) HTTPS request received for child 203 (server test.com:443)                Apache-Fehler
2017-04-14 20:43:07    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of Require user "test" "admin": denied (no authenticated user yet)                Apache-Fehler
2017-04-14 20:43:07    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)                Apache-Fehler
2017-04-14 20:43:07    Error    123.123.123.123        [auth_digest:info] AH01778: user test: nonce expired (414.00 seconds old - max lifetime 300.00) - sending new nonce                Apache-Fehler
2017-04-14 20:43:07    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of Require all granted: granted                Apache-Fehler
2017-04-14 20:43:07    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: granted                Apache-Fehler
2017-04-14 20:43:08    Access    123.123.123.123    204    PUT /fileserver/private/test/256MB HTTP/1.0        Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)    430     SSL/TLS-Zugriff für Apache
2017-04-14 20:43:08    Access    123.123.123.123    207    PROPPATCH /fileserver/private/test/256MB HTTP/1.0        Mountain Duck/1.8.3.6544 (Windows 10/10.0) (x86)    811     SSL/TLS-Zugriff für Apache
2017-04-14 20:43:08    Error            [headers:debug] mod_headers.c(823): AH01502: headers: ap_headers_output_filter()                Apache-Fehler
2017-04-14 20:43:08    Error    123.123.123.123        [ssl:debug] ssl_engine_kernel.c(224): AH02034: Initial (No.1) HTTPS request received for child 80 (server test.com:443)                Apache-Fehler
2017-04-14 20:43:08    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of Require user "test" "admin": denied (no authenticated user yet)                Apache-Fehler
2017-04-14 20:43:08    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)                Apache-Fehler
2017-04-14 20:43:08    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of Require user "test" "admin": granted                Apache-Fehler
2017-04-14 20:43:08    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: granted                Apache-Fehler
2017-04-14 20:43:08    Error    123.123.123.123        [ssl:debug] ssl_engine_kernel.c(224): AH02034: Initial (No.1) HTTPS request received for child 207 (server test.com:443)                Apache-Fehler
2017-04-14 20:43:08    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of Require user "test" "admin": denied (no authenticated user yet)                Apache-Fehler
2017-04-14 20:43:08    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)                Apache-Fehler
2017-04-14 20:43:08    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of Require user "test" "admin": granted                Apache-Fehler
2017-04-14 20:43:08    Error    123.123.123.123        [authz_core:debug] mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: granted                Apache-Fehler
2017-04-14 20:43:08    Error            [headers:debug] mod_headers.c(823): AH01502: headers: ap_headers_output_filter()                Apache-Fehler

does this make any sense to you?

Thanks!!
 
what just pops into my eyes is this:

Code:
2017-04-14 20:43:07    Error    123.123.123.123        [auth_digest:info] AH01778: user test: nonce expired (414.00 seconds old - max lifetime 300.00) - sending new nonce                Apache-Fehler

That would at least fit my ~ 260seconds time frame. I've looked up mod_auth_digest and there's a directive called
Code:
AuthDigestNonceLifetime 300

Where would i set that?
 
Hi DReffects,

to avoid nginx storing body content in temporary files, you have to set for example:
Code:
client_body_buffer_size 512M;
client_max_body_size 512M;
( both settings have to have the same size - definitions! )

For more informations here, pls. see the official NGINX - docs:



AuthDigestNonceLifetime
... would be set in the root directory of your (sub)domain in a ".htaccess" - file.
 
Hi @UFHH01 ,

if i set both client_body_buffer and client_max_body_size to 512M this would also limit any upload to 512MB, right?
Is there a downside to storing temporary files? I'd like to enable uploads up to 4GB - from what I understand setting the client_body_buffer_size to 4GB would also require lots of free RAM.

... would be set in the root directory of your (sub)domain in a ".htaccess" - file.
I've tried setting this in the /var/www/vhosts/fs/private directory but it had no effect.

Setting AuthDigestNonceLifetime to 999 seconds in

Code:
/usr/local/psa/admin/conf/file_sharing.conf

solved my issues.

Here's the section:

Code:
<Directory "/var/www/vhosts/fs/private">
  Options +Indexes
  Dav On
  AuthType Digest
  AuthDigestNonceLifetime 300 (that's the default, not in the config)
  now set to:
  AuthDigestNonceLifetime 999
  AuthName "File Sharing Area"
  AuthDigestProvider file
  AuthUserFile "/var/www/vhosts/fs-passwd/dav.passwd"
  AuthDigestDomain "/fileserver"

The only problem is, that the file_sharing.conf file seems to be auto-generated - do you know where the file gets its initial values from?
EDIT: Nevermind, found it: /usr/local/psa/admin/application/smb/config/file-sharing/file-sharing.conf


So summarizing the whole thing (please correct me, if I am wrong - I'd like to understand this):
Uploading to nginx worked from the get go, but during the transfer the AuthDigest Nonce thingy expired. When the upload finished and the client tries to finish up the transfer it had to re-authenticate and this resulted in nginx dropping the file?

If that's the case this whole thing seems to be flaud by design if you intend to use the Plesk filesharing feature to share files. Anything below 50MB would be shared by e-mail, anything above 50MB will probably fail unless you have a really fast upload speed since you won't get larger files transfered in under 300 seconds.

Speaking of 4GB Files: Uploading a file this large would take around 17 hours and 21 Minutes with 512kbit of Upload speed. Is it viable to raise the AuthDigestNonceLifetime to such a high value or even use 0 to have the nonce never expire?
 
Last edited:
Back
Top