t0: 1772481536.203
argv: /usr/bin/python3 /usr/lib/python3.12/site-packages/copyparty/__main__.py -c /z/initcfg --chdir=/w --no-crt -e2dsa -e2ts --shr-adm=chamook -sss --no-robots

[36mcopyparty v1.20.10 "[35msftp is fine too[36m" (2026-02-25)
  CPython v3.12.12 on Linux64  [90m[GCC 15.2.0][0;36m
   sqlite 3.51.2*1 | jinja 3.1.6 | pyftpd 1.5.10 | tftp 0.4.0 | miko 4.0.0
[0m
[+] opened logfile [cpp-2026-0302-195857.txt.xz]
2026-03-02
19:58:57.994 root                   LOG: creating new sessions-db /cfg/copyparty/sessions.db
19:58:58.016 root                   LOG: created new sessions-db
19:58:58.530 auth                   BTW: discovered config files in /cfg => ['party.conf']
19:58:58.530 auth                   LOG: loaded 2 config files:
└/z/initcfg
 └/cfg/party.conf
19:59:00.832 auth                   LOG: volumes and permissions:

"/"  /w
|    read:  chamook
|   write:  everybody
|    move:  chamook
|  delete:  chamook
|    dots:  chamook
|     get:  everybody
|   upGet:  everybody
|    html:  --none--
|  uadmin:  chamook

19:59:00.832 auth                   BTW: hint: enable upload deduplication with --dedup (but see readme for consequences)
19:59:00.832 auth                  CRIT: anyone can write to the current directory: /w

19:59:00.844 auth                   LOG: added 1 new sessions (chamook)
19:59:01.291 auth                   LOG: {'users': ['chamook', '*'], 'vols': ['/'], 'flags': ['ln', 'p', 'r']}
19:59:01.291 auth                   LOG: /: read({'chamook'}) write({'chamook', '*'}) move({'chamook'}) del({'chamook'}) dots({'chamook'}) get({'chamook', '*'}) upGet({'chamook', '*'}) html(set()) uadmin({'chamook'})
19:59:01.291 auth                   LOG: checking / as chamook
19:59:01.639 auth                   LOG: checking / as *
19:59:01.640 root                   LOG: max clients: 1024
19:59:01.642 tcpsrv                 LOG: available @  http://127.0.0.1:3923/  (1-lo)
19:59:01.642 tcpsrv                 LOG: available @  http://[::1]:3923/  (1-lo)
19:59:01.642 tcpsrv                 LOG: available @  http://10.42.1.224:3923/  (2-eth0, external)
19:59:01.642 tcpsrv                 LOG: available @  http://[fe80::5c6d:76ff:fe6e:6965]:3923/  (2-eth0, external)
19:59:01.645 optional-dependencies  BTW: OK: sqlite, pillow, vips, pillow-webp, ffmpeg, ffprobe, argon2, pyzmq, rawpy, NG: mutagen, pillow-heif, pillow-avif, see --deps (this is fine btw)
19:59:01.645 thumb                  BTW: setting --no-acode because --no-thumb (sorry)
19:59:01.728 tcpsrv                 LOG: listening @ [::]:3923  f4 p1
19:59:01.728 hsrv                   LOG: subscribed @ [::]:3923  f4 p1
19:59:01.728 root                   LOG: workers OK

19:59:01.728 cert                  WARN: using default TLS certificate; https will be insecure: /cfg/copyparty/cert.pem
19:59:02.626 up2k                   LOG: / dathumb dithumb dvthumb nodupe casechk:n fk:4 fsnt:lin lifetime:864000
19:59:04.797 10.42.1.213 38616     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:04.798 10.42.1.213 38616     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:04.798 10.42.1.213 38616      LOG: GET  / @*
19:59:05.398 10.42.1.213 38616     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:05.399 10.42.1.213 38616     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:05.400 10.42.1.213 38624     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:05.400 10.42.1.213 38624     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:05.401 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:05.405 10.42.1.213 38650     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:05.405 10.42.1.213 38644     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:05.405 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:05.406 10.42.1.213 38652     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:05.406 10.42.1.213 38650     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:05.406 10.42.1.213 38644     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:05.407 10.42.1.213 38652     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:05.497 10.42.1.213 38652     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:05.497 10.42.1.213 38652     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:05.497 10.42.1.213 38652      LOG: GET  /?tree= @*
19:59:05.506 10.42.1.213 38652     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:05.506 10.42.1.213 38652     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:05.786 10.42.1.213 38652     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:05.786 10.42.1.213 38652     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:05.786 10.42.1.213 38652      LOG: GET  / @*
19:59:06.452 u2idx                  LOG: opened '/w/.hist/up2k.db'
19:59:06.517 10.42.1.213 38650     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:06.517 10.42.1.213 38650     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:06.900 10.42.1.213 38652      BTW: http400: client d/c while replying body, '/'
19:59:06.900 10.42.1.213 38652      LOG: shut(13): ok; client has already disconnected; 107
19:59:07.563 10.42.1.213 38650     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:07.563 10.42.1.213 38650     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:07.563 10.42.1.213 38650      LOG: GET  /setup/ @*
19:59:07.970 10.42.1.213 38650     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:07.970 10.42.1.213 38650     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:07.970 10.42.1.213 38650      LOG: POST /_internal/api/setup.php?action=exists @*
19:59:07.970 10.42.1.213 38650      LOG: POST len=2 type=utf-8 ip=10.42.1.213 user=* req='/_internal/api/setup.php?action=exists' json={}
19:59:07.979 10.42.1.213 38650     WARN: http500: httpcli.py:850 <run>: return self.handle_post() and self.keepalive
httpcli.py:2218 <handle_post>: return self.handle_post_json()
httpcli.py:2918 <handle_post_json>: name = undot(body["name"])
[KeyError] 'name', '/_internal/api/setup.php'
19:59:08.018 10.42.1.213 38644     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:08.018 10.42.1.213 38644     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:08.019 10.42.1.213 38644      LOG: POST /_internal/api/setup.php?action=exists @*
19:59:08.019 10.42.1.213 38644      LOG: POST len=2 type=utf-8 ip=10.42.1.213 user=* req='/_internal/api/setup.php?action=exists' json={}
19:59:08.022 10.42.1.213 38644     WARN: http500: httpcli.py:850 <run>: return self.handle_post() and self.keepalive
httpcli.py:2218 <handle_post>: return self.handle_post_json()
httpcli.py:2918 <handle_post_json>: name = undot(body["name"])
[KeyError] 'name', '/_internal/api/setup.php'
19:59:08.238 up2k                   LOG: created DB at /w/.hist/up2k.db
19:59:08.288 mtag                  WARN: could not load Mutagen, trying FFprobe instead
19:59:08.288 mtag                  WARN: found FFprobe but it was disabled by --no-mtag-ff
19:59:08.288 mtag                  CRIT: need Mutagen or FFprobe to read media tags so please run this:
                                     python3 -m pip install --user mutagen

19:59:08.289 up2k                  WARN: uploads temporarily blocked due to indexing
19:59:08.299 up2k                   LOG: commit 1 new files; 2 updates
19:59:08.300 up2k                   LOG: uploads are now possible
19:59:08.300 up2k                   LOG: online (reading tags) [/w]
19:59:08.327 up2k                   LOG: 1 volumes in 6.60 sec
19:59:08.327 up2k                  CRIT: could not read tags because no backends are available (Mutagen or FFprobe)
19:59:08.580 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:08.580 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:08.580 10.42.1.213 38626      LOG: GET  /api/user/ @*
19:59:08.757 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:08.757 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:08.757 10.42.1.213 38626      LOG: GET  / @*
19:59:09.909 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:09.909 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:09.909 10.42.1.213 38626      LOG: GET  /console/ @*
19:59:11.265 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:11.266 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:11.266 10.42.1.213 38626      LOG: GET  /server @*
19:59:11.955 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:11.955 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:11.955 10.42.1.213 38626      LOG: GET  /server-status @*
19:59:14.150 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:14.150 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:14.150 10.42.1.213 38626      LOG: GET  /about @*
19:59:15.084 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:15.084 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:15.084 10.42.1.213 38626      LOG: GET  /login.action @*
19:59:16.219 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:16.219 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:16.219 10.42.1.213 38626      LOG: GET  /v2/_catalog @*
19:59:16.666 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:16.666 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:17.789 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:17.789 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:17.789 10.42.1.213 38626      LOG: GET  /.env @*
19:59:18.561 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:18.561 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:18.561 10.42.1.213 38626      LOG: GET  / @*
19:59:19.463 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:19.463 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:19.463 10.42.1.213 38626      LOG: GET  /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application @*
19:59:21.468 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:21.468 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:21.468 10.42.1.213 38626      LOG: GET  /.git/config @*
19:59:22.621 10.42.1.213 38626     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:22.621 10.42.1.213 38626     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:22.621 10.42.1.213 38626      LOG: POST /graphql @*
19:59:22.621 10.42.1.213 38626      LOG: POST len=92 type=utf-8 ip=10.42.1.213 user=* req='/graphql' json={'query': 'query IntrospectionQuery{__schema{queryType{name} types{name} directives{name}}}'}
19:59:22.625 10.42.1.213 38626     WARN: http500: httpcli.py:850 <run>: return self.handle_post() and self.keepalive
httpcli.py:2218 <handle_post>: return self.handle_post_json()
httpcli.py:2918 <handle_post_json>: name = undot(body["name"])
[KeyError] 'name', '/graphql'
19:59:22.708 10.42.1.213 38624     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:22.709 10.42.1.213 38624     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:22.709 10.42.1.213 38624      LOG: POST /api @*
19:59:22.709 10.42.1.213 38624      LOG: POST len=92 type=utf-8 ip=10.42.1.213 user=* req='/api' json={'query': 'query IntrospectionQuery{__schema{queryType{name} types{name} directives{name}}}'}
19:59:22.713 10.42.1.213 38624     WARN: http500: httpcli.py:850 <run>: return self.handle_post() and self.keepalive
httpcli.py:2218 <handle_post>: return self.handle_post_json()
httpcli.py:2918 <handle_post_json>: name = undot(body["name"])
[KeyError] 'name', '/api'
19:59:22.787 10.42.1.213 38616     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:22.787 10.42.1.213 38616     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:22.787 10.42.1.213 38616      LOG: POST /api/graphql @*
19:59:22.787 10.42.1.213 38616      LOG: POST len=92 type=utf-8 ip=10.42.1.213 user=* req='/api/graphql' json={'query': 'query IntrospectionQuery{__schema{queryType{name} types{name} directives{name}}}'}
19:59:22.790 10.42.1.213 38616     WARN: http500: httpcli.py:850 <run>: return self.handle_post() and self.keepalive
httpcli.py:2218 <handle_post>: return self.handle_post_json()
httpcli.py:2918 <handle_post_json>: name = undot(body["name"])
[KeyError] 'name', '/api/graphql'
19:59:22.889 10.42.1.213 57616     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:22.889 10.42.1.213 57616     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:22.889 10.42.1.213 57616      LOG: POST /graphql/api @*
19:59:22.889 10.42.1.213 57616      LOG: POST len=92 type=utf-8 ip=10.42.1.213 user=* req='/graphql/api' json={'query': 'query IntrospectionQuery{__schema{queryType{name} types{name} directives{name}}}'}
19:59:22.892 10.42.1.213 57616     WARN: http500: httpcli.py:850 <run>: return self.handle_post() and self.keepalive
httpcli.py:2218 <handle_post>: return self.handle_post_json()
httpcli.py:2918 <handle_post_json>: name = undot(body["name"])
[KeyError] 'name', '/graphql/api'
19:59:22.957 10.42.1.213 57622     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:22.958 10.42.1.213 57622     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:22.958 10.42.1.213 57622      LOG: POST /api/gql @*
19:59:22.958 10.42.1.213 57622      LOG: POST len=92 type=utf-8 ip=10.42.1.213 user=* req='/api/gql' json={'query': 'query IntrospectionQuery{__schema{queryType{name} types{name} directives{name}}}'}
19:59:22.960 10.42.1.213 57622     WARN: http500: httpcli.py:850 <run>: return self.handle_post() and self.keepalive
httpcli.py:2218 <handle_post>: return self.handle_post_json()
httpcli.py:2918 <handle_post_json>: name = undot(body["name"])
[KeyError] 'name', '/api/gql'
19:59:23.486 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:23.486 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:23.486 10.42.1.213 57634      LOG: GET  /s/2353e2334313e2035313e29383/_/;/META-INF/maven/com.atlassian.jira/jira-webapp-dist/pom.properties @*
19:59:24.485 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:24.485 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:24.485 10.42.1.213 57634      LOG: GET  /config.json @*
19:59:25.960 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:25.960 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:25.960 10.42.1.213 57634      LOG: GET  / @*
19:59:26.485 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:26.485 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:26.485 10.42.1.213 57634      LOG: GET  /telescope/requests @*
19:59:26.550 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:26.551 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:26.551 10.42.1.213 57634      LOG: GET  /info.php @*
19:59:27.763 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:27.763 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:27.763 10.42.1.213 57634      LOG: GET  /.well-known/security.txt @*
19:59:28.567 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:28.568 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:28.568 10.42.1.213 57634      LOG: GET  /actuator/env @*
19:59:30.581 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:30.581 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:30.581 10.42.1.213 57634      LOG: GET  /swagger-ui.html @*
19:59:31.569 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:31.569 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:31.569 10.42.1.213 57634      LOG: GET  /swagger/index.html @*
19:59:32.581 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:32.582 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:32.582 10.42.1.213 57634      LOG: GET  /swagger/swagger-ui.html @*
19:59:33.570 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:33.571 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:33.571 10.42.1.213 57634      LOG: GET  /webjars/swagger-ui/index.html @*
19:59:34.660 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:34.661 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:34.661 10.42.1.213 57634      LOG: GET  /swagger.json @*
19:59:35.579 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:35.579 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:35.579 10.42.1.213 57634      LOG: GET  /swagger/v1/swagger.json @*
19:59:36.694 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:36.694 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:36.694 10.42.1.213 57634      LOG: GET  /v2/api-docs @*
19:59:37.645 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:37.646 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:37.646 10.42.1.213 57634      LOG: GET  /v3/api-docs @*
19:59:38.658 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:38.658 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:38.658 10.42.1.213 57634      LOG: GET  /api-docs/swagger.json @*
19:59:39.646 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:39.646 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:39.647 10.42.1.213 57634      LOG: GET  /api/swagger.json @*
19:59:40.648 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:40.648 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:40.648 10.42.1.213 57634      LOG: GET  /@vite/env @*
19:59:41.634 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:41.635 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:41.635 10.42.1.213 57634      LOG: GET  /.vscode/sftp.json @*
19:59:42.028 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:42.028 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:42.028 10.42.1.213 57634      LOG: GET  / @*
19:59:42.646 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:42.646 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:42.646 10.42.1.213 57634      LOG: OPTIONS / @*
19:59:43.646 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:43.647 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:43.647 10.42.1.213 57634      LOG: GET  /?rest_route=/wp/v2/users/ @*
19:59:44.637 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:44.637 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:44.637 10.42.1.213 57634      LOG: GET  /debug/default/view?panel=config @*
19:59:55.972 10.42.1.213 57634     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:55.972 10.42.1.213 57634     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:55.974 10.42.1.213 48858     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:55.974 10.42.1.213 48858     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:56.233 10.42.1.213 48872     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:56.234 10.42.1.213 48872     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:56.234 10.42.1.213 48872      LOG: GET  /%3Fb%3Du @*
19:59:56.234 10.42.1.213 48872      LOG:  `-- '?b=u'
19:59:56.681 10.42.1.213 48872     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:56.681 10.42.1.213 48872     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:56.681 10.42.1.213 48872      LOG: GET  /%3Fh @*
19:59:56.681 10.42.1.213 48872      LOG:  `-- '?h'
19:59:56.892 10.42.1.213 48872     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:56.893 10.42.1.213 48872     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:56.893 10.42.1.213 48872      LOG: GET  /%23 @*
19:59:56.893 10.42.1.213 48872      LOG:  `-- '#'
19:59:57.042 10.42.1.213 48872     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:57.042 10.42.1.213 48872     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:57.043 10.42.1.213 48872      LOG: GET  / @*
19:59:57.043 10.42.1.213 48878     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:57.044 10.42.1.213 48878     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:57.110 10.42.1.213 48872     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:57.110 10.42.1.213 48872     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:57.194 10.42.1.213 48872     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:57.194 10.42.1.213 48872     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:58.688 10.42.1.213 48872     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:58.688 10.42.1.213 48872     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:58.802 10.42.1.213 48872     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



19:59:58.802 10.42.1.213 48872     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



19:59:58.802 10.42.1.213 48872     WARN: cors-reject POST because request-header Origin='https://copyparty.chaminy.house' does not match request-protocol 'http://' and host 'copyparty.chaminy.house' based on request-header Host='copyparty.chaminy.house' (note: if this request is not malicious, check if your reverse-proxy is accidentally modifying request headers, in particular 'Origin', for example by running copyparty with --ihead='*' to show all request headers)
19:59:58.802 10.42.1.213 48872     WARN: http403: rejected by cors-check (see fileserver log), '/'
20:00:04.121 10.42.1.213 48878     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



20:00:04.122 10.42.1.213 48878     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



20:00:04.122 10.42.1.213 48878     WARN: cors-reject POST because request-header Origin='https://copyparty.chaminy.house' does not match request-protocol 'http://' and host 'copyparty.chaminy.house' based on request-header Host='copyparty.chaminy.house' (note: if this request is not malicious, check if your reverse-proxy is accidentally modifying request headers, in particular 'Origin', for example by running copyparty with --ihead='*' to show all request headers)
20:00:04.122 10.42.1.213 48878     WARN: http403: rejected by cors-check (see fileserver log), '/'
20:00:09.240 10.42.1.213 44976     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



20:00:09.240 10.42.1.213 44976     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



20:00:09.240 10.42.1.213 44976      LOG: GET  /?h @*
20:00:09.291 10.42.1.213 44976     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



20:00:09.291 10.42.1.213 44976     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



20:00:09.292 10.42.1.213 44992     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



20:00:09.292 10.42.1.213 44992     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



20:00:45.668 10.42.1.213 44992     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



20:00:45.668 10.42.1.213 44992     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



20:00:45.669 10.42.1.213 44992      LOG: GET  /?h @*
20:00:45.739 10.42.1.213 44992     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



20:00:45.739 10.42.1.213 44992     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



20:00:45.739 10.42.1.213 44992      LOG: GET  /favicon.ico @*
20:00:46.981 10.42.1.213 44992     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



20:00:46.981 10.42.1.213 44992     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



20:00:46.981 10.42.1.213 44992      LOG: GET  /?h @*
20:00:48.455 10.42.1.213 44992     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



20:00:48.455 10.42.1.213 44992     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



20:00:48.456 10.42.1.213 44992      LOG: GET  / @*
20:00:48.540 10.42.1.213 44992     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



20:00:48.540 10.42.1.213 44992     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



20:00:48.540 10.42.1.213 44992      LOG: GET  /?tree= @*
20:00:49.558 10.42.1.213 44992     WARN: could not determine the client's IP-address because the global-option --rproxy has not been configured, so the request-header [x-forwarded-for] specified by global-option --xff-hdr cannot be used safely! The raw header value was [10.42.0.0]. Please see the "reverse-proxy" section in the readme. The best approach is to configure your reverse-proxy to give copyparty the exact IP-address to assume (perhaps in another header), but you may also try the following:

  rproxy: -1   if this client's IP-address is [10.42.0.0]

Furthermore, the following request-headers are also relevant, and you should check that the values below are sensible:

  request-header [x-forwarded-proto] (configured with global-option --xf-proto) has the value [https]; this should be the protocol that the webbrowser is using, so either 'http' or 'https'

  request-header [x-forwarded-host] (configured with global-option --xf-host) has the value [copyparty.chaminy.house]; this should be the website domain or external IP-address which the webbrowser is accessing



20:00:49.558 10.42.1.213 44992     WARN: got header "x-forwarded-for" from untrusted source "10.42.1.213" claiming the true client ip is "10.42.1.213" (raw value: "10.42.0.0");  if you trust this, you must allowlist this proxy with global-option "xff-src: 10.42.0.0/16" or global-option "xff-src: lan"  Note: depending on your reverse-proxy, and/or WAF, and/or other intermediates, you may want to read the true client IP from another header by also specifying global-option "xff-hdr: SomeOtherHeader". Some copyparty features are now disabled as a safety measure.



20:00:56.181 hsrv                   LOG: ok bye
20:00:56.181 tcpsrv                 LOG: ok bye
20:00:56.181 up2k                   LOG: writing snapshot
20:00:56.186 root                   LOG: nailed it
