t0: 1772481662.504
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-200102.txt.xz]
2026-03-02
20:01:02.774 root                   LOG: creating new sessions-db /cfg/copyparty/sessions.db
20:01:02.792 root                   LOG: created new sessions-db
20:01:02.796 auth                   BTW: discovered config files in /cfg => ['party.conf']
20:01:02.796 auth                   LOG: loaded 2 config files:
└/z/initcfg
 └/cfg/party.conf
20:01:02.798 auth                   LOG: volumes and permissions:

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

20:01:02.798 auth                   BTW: hint: enable upload deduplication with --dedup (but see readme for consequences)
20:01:02.801 auth                   LOG: added 1 new sessions (chamook)
20:01:02.812 auth                   LOG: {'users': ['chamook', '*'], 'vols': ['/'], 'flags': ['ln', 'p', 'r']}
20:01:02.812 auth                   LOG: /: read({'chamook'}) write({'chamook'}) move({'chamook'}) del({'chamook'}) dots({'chamook'}) get(set()) upGet(set()) html(set()) uadmin({'chamook'})
20:01:02.812 auth                   LOG: checking / as chamook
20:01:02.815 auth                   LOG: checking / as *
20:01:02.815 root                   LOG: max clients: 1024
20:01:02.816 tcpsrv                 LOG: available @  http://127.0.0.1:3923/  (1-lo)
20:01:02.816 tcpsrv                 LOG: available @  http://[::1]:3923/  (1-lo)
20:01:02.816 tcpsrv                 LOG: available @  http://10.42.1.225:3923/  (2-eth0, external)
20:01:02.816 tcpsrv                 LOG: available @  http://[fe80::fcde:77ff:fe5b:d9a]:3923/  (2-eth0, external)
20:01:02.820 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)
20:01:02.820 thumb                  BTW: setting --no-acode because --no-thumb (sorry)
20:01:02.900 tcpsrv                 LOG: listening @ [::]:3923  f4 p1
20:01:02.901 hsrv                   LOG: subscribed @ [::]:3923  f4 p1
20:01:02.901 root                   LOG: workers OK

20:01:02.901 cert                  WARN: using default TLS certificate; https will be insecure: /cfg/copyparty/cert.pem
20:01:02.903 up2k                   LOG: / dathumb dithumb dvthumb nodupe casechk:n fk:4 fsnt:lin lifetime:864000
20:01:02.931 up2k                   LOG:   /w/.hist/up2k.db |1|
20:01:02.931 mtag                  WARN: could not load Mutagen, trying FFprobe instead
20:01:02.931 mtag                  WARN: found FFprobe but it was disabled by --no-mtag-ff
20:01:02.931 mtag                  CRIT: need Mutagen or FFprobe to read media tags so please run this:
                                     python3 -m pip install --user mutagen

20:01:02.931 up2k                  WARN: uploads temporarily blocked due to indexing
20:01:02.933 up2k                   LOG: reindex '/w' => 'cpp-2026-0302-195857.txt.xz' mtime(1772481537/1772481656) size(0/4788)
20:01:02.943 up2k                   LOG: commit 2 new files; 4 updates
20:01:02.947 up2k                   LOG: uploads are now possible
20:01:02.947 up2k                   LOG: online (reading tags) [/w]
20:01:02.979 up2k                   LOG: 1 volumes in 0.08 sec
20:01:02.979 up2k                  CRIT: could not read tags because no backends are available (Mutagen or FFprobe)
20:01:09.506 10.42.1.213 35776     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:01:09.506 10.42.1.213 35776     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:01:09.506 10.42.1.213 35776      LOG: GET  / @*
20:01:09.546 10.42.1.213 35776     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:01:09.546 10.42.1.213 35776     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:01:09.547 10.42.1.213 35780     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:01:09.550 10.42.1.213 35786     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:01:09.550 10.42.1.213 35784     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:01:09.550 10.42.1.213 35780     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:01:09.550 10.42.1.213 35786     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:01:09.550 10.42.1.213 35784     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:01:14.714 10.42.1.213 35784     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:01:14.714 10.42.1.213 35784     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:01:14.714 10.42.1.213 35784      LOG: GET  / @*
20:01:18.083 10.42.1.213 35784     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:01:18.083 10.42.1.213 35784     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:01:18.083 10.42.1.213 35784      LOG: GET  /?h @*
20:01:22.584 10.42.1.213 35784     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:01:22.585 10.42.1.213 35784     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:01:22.585 10.42.1.213 35784      LOG: GET  / @*
20:01:22.854 10.42.1.213 35784     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:01:22.854 10.42.1.213 35784     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:01:22.856 10.42.1.213 35780     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:01:22.856 10.42.1.213 35780     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:01:22.857 10.42.1.213 35784     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:01:22.857 10.42.1.213 35784     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:01:22.857 10.42.1.213 35786     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:01:22.857 10.42.1.213 35786     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:01:23.322 10.42.1.213 35780     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:01:23.322 10.42.1.213 35780     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:01:23.322 10.42.1.213 35780      LOG: GET  /favicon.ico @*
20:01:24.953 10.42.1.213 35780     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:01:24.953 10.42.1.213 35780     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:01:24.953 10.42.1.213 35780      LOG: GET  / @*
20:01:25.118 10.42.1.213 35776     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:01:25.119 10.42.1.213 35776     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:01:25.120 10.42.1.213 35784     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:01:25.120 10.42.1.213 35786     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:01:25.121 10.42.1.213 35786     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:01:25.121 10.42.1.213 35784     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:01:25.122 10.42.1.213 35780     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:01:25.122 10.42.1.213 35780     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:01:25.425 10.42.1.213 35780     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:01:25.425 10.42.1.213 35780     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:01:25.426 10.42.1.213 35780      LOG: GET  /favicon.ico @*
20:01:31.893 10.42.1.213 35780     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:01:31.893 10.42.1.213 35780     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:01:31.893 10.42.1.213 35780     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:01:31.893 10.42.1.213 35780     WARN: http403: rejected by cors-check (see fileserver log), '/'
20:02:01.197 10.42.1.213 35784     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:02:01.197 10.42.1.213 35784     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:02:01.197 10.42.1.213 35784      LOG: HEAD / @*
20:02:01.482 10.42.1.213 35784     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:02:01.482 10.42.1.213 35784     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:02:01.482 10.42.1.213 35784      LOG: GET  / @* [0-2048]
20:02:02.670 10.42.1.213 35784     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:02:02.670 10.42.1.213 35784     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:02:02.670 10.42.1.213 35784      LOG: HEAD /_next @*
20:02:02.670 10.42.1.213 35784      LOG: @* has no access to '/_next'
20:02:07.436 10.42.1.213 35784     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:02:07.436 10.42.1.213 35784     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:02:07.436 10.42.1.213 35784      LOG: GET  / @*
20:02:09.477 10.42.1.213 35784     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:02:09.477 10.42.1.213 35784     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:02:09.477 10.42.1.213 35784      LOG: GET  /setup/ @*
20:02:09.477 10.42.1.213 35784      LOG: @* has no access to '/setup'
20:02:09.517 10.42.1.213 35784     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:02:09.518 10.42.1.213 35784     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:02:09.518 10.42.1.213 35784      LOG: POST /_internal/api/setup.php?action=exists @*
20:02:09.518 10.42.1.213 35784      LOG: POST len=2 type=utf-8 ip=10.42.1.213 user=* req='/_internal/api/setup.php?action=exists' json={}
20:02:09.523 10.42.1.213 35784     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'
20:02:09.563 10.42.1.213 35776     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:02:09.563 10.42.1.213 35776     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:02:09.564 10.42.1.213 35776      LOG: POST /_internal/api/setup.php?action=exists @*
20:02:09.564 10.42.1.213 35776      LOG: POST len=2 type=utf-8 ip=10.42.1.213 user=* req='/_internal/api/setup.php?action=exists' json={}
20:02:09.568 10.42.1.213 35776     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'
20:02:09.694 10.42.1.213 35786     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:02:09.694 10.42.1.213 35786     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:02:09.694 10.42.1.213 35786      LOG: GET  /api/user/ @*
20:02:09.694 10.42.1.213 35786      LOG: @* has no access to '/api/user'
20:03:23.343 hsrv                   LOG: ok bye
20:03:23.343 tcpsrv                 LOG: ok bye
20:03:23.343 up2k                   LOG: writing snapshot
20:03:23.347 root                   LOG: nailed it
