Dear Maintainer,

after last update, when i click 'start sharing' on a file share my
logs are showing

[2026-08-11 11:51:33,548] ERROR in app: Exception on / [GET]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/lib/python3/dist-packages/flask/app.py", line 919, in
full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/lib/python3/dist-packages/flask/app.py", line 917, in
full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/lib/python3/dist-packages/flask/app.py", line 902, in
dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
 # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/onionshare_cli/web/share_mode.py",
line 160, in index
    self.filesize = self.gzip_filesize
                    ^^^^^^^^^^^^^^^^^^
AttributeError: 'ShareModeWeb' object has no attribute 'gzip_filesize'

also a bunch of HTTP 500s in the logs

meanwhile it's still saying "Starting..." on the green button but
the progress % also isn't present anymore

[ie it's almost like onionshare is allowing visits to the website
before it is initialized]

I cannot reproduce you issue. If I try to share files with uptodate sid it
works without any issues. Additionally I see no 500s in the logs. Can you run
onionshare -v and provide the log? You can also try to use
onionshare-cli -v FILES
that should reduce the logs to a bare minimum. Keep in mind, that in the logs
the filenames are shared.
How big are the files you try to share? As onionshare compresses the files.

For me it looks like you have a bot targeting your onionservice before it is
ready and that's why gzip_filesize isn't already set. Because from the code
paths gzip_filesize should be set after the compression step is done.

Regards,

hefee

One of them is ~30GiB. The whole collection is about ~40GiB

Control: tags -1 +upstream -unreproducible

Upps, that is a big size ;) There is a upstream bugreport about sharing 90GB
(#1114). The workaround found is to use the cli. Nice that they found a
workaround, but the UI should tell the user, that it does not support big files
or fix the underlying zipping issue.

(#1114) https://github.com/onionshare/onionshare/issues/1114

And the other issue about the 500s in the logs this is different issue. My
guess is, that while zipping the files the hidden service is already started.
For small testfiles the timeframe between opening the hidden service and finish
the zipping is too short to fail.
Properly it should wait to start the hidden service until the zipping has
finished.

Can you create those issues on upstream, as it would be a lot easier if you
can provide more details and I do not need to proxy the conversation:

https://github.com/onionshare/onionshare/issues/

If you create issues please send a follow up to this bugreport, so I can link
the Debian BTS to the issue(s) on upstream.

can provide more details and I do not need to proxy the conversation:

No.  I don't have access to github, nor do I condone its use.
or fix the underlying zipping issue.

The zipping/big files issue has already been reported to another bug
report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1127323 and
is separate to this issue.
finished.

Yes that's the problem in this report.
can provide more details and I do not need to proxy the conversation:

Please don't say/"proxy" anything to github especially on my behalf.
It should be treated as
an adversary of all debian users.

Jeff Cliff