[Bug]: File Request feature "suddenly" does not ask for nickname any more

[Darkwing371]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Installed Nextcloud 33 fresh a couple of days ago. Used it to create Shares via links, to let people be able to upload files. I used the File Request feature (upload only) for this. (But also tried the other options.)

When I tested the Share links, there was a modal, asking (forcing) the recipient to input a nickname. The nickname then also was used as a directory for the uploaded files. After entering the nickname, the recipient's browser remembered this nickname. All this was accompanied by the small avatar in the top right corner showing the first letter of the provided nickname.

Two or three days later (yesterday, at time of writing), all this stopped. I noticed, that "suddenly" this modal does not appear any more. The user is not asked and forced to provide a nickname. The avatar shows a question mark and sais "You are currently not identified" and offers the option to "Set public name".

Only after clicking "Set public name" the modal for guest identification appears.

At first I thought that it maybe a browser cache problem. These things often times are a spoke in the wheel, when testing websites. But in the meantime I tried this on three different platforms and in multiple browsers: the behavior stays the same: no guest identification modal any more.

Steps to reproduce

I don't know how to reproduce this, sorry. All I did was:

1. Nextcloud GUI file browser
2. Selected a directory
3. Clicked on Share options
4. Created a public Share link

When visiting this link, at first there was a modal for guest identification. Now there isn't any more.

Expected behavior

I expected the modal for guest identification to appear every time a new recipient uses such a Share link.

To be honest: I also expected that, when creating such a Share link, it is an option whether guest identification should be enforced or not (and thus anonymous with no directory is ok). I also expected an option, or at least an info about, how long the user's browser will (or should) remember the identified guest. (Well, it seems I'm not the only one wondering about that.) See this a kind of a feature request.

Nextcloud Server version

33

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.4

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "192.168.0.192"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "33.0.0.16",
        "overwrite.cli.url": "http:\/\/192.168.0.192",
        "htaccess.RewriteBase": "\/",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "maintenance": false,
        "simpleSignUpLink.shown": false,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "default_phone_region": "DE",
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 0
        },
        "config_preset": 2,
        "forbidden_filename_basenames": [
            "con",
            "prn",
            "aux",
            "nul",
            "com0",
            "com1",
            "com2",
            "com3",
            "com4",
            "com5",
            "com6",
            "com7",
            "com8",
            "com9",
            "com\u00b9",
            "com\u00b2",
            "com\u00b3",
            "lpt0",
            "lpt1",
            "lpt2",
            "lpt3",
            "lpt4",
            "lpt5",
            "lpt6",
            "lpt7",
            "lpt8",
            "lpt9",
            "lpt\u00b9",
            "lpt\u00b2",
            "lpt\u00b3"
        ],
        "forbidden_filename_characters": [
            "<",
            ">",
            ":",
            "\"",
            "|",
            "?",
            "*",
            "\\",
            "\/"
        ],
        "forbidden_filename_extensions": [
            " ",
            ".",
            ".filepart",
            ".part"
        ],
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": true,
        "mail_smtpport": "465",
        "mail_sendmailmode": "smtp",
        "mail_smtpstreamoptions": {
            "ssl": {
                "allow_self_signed": false,
                "verify_peer": true,
                "verify_peer_name": true
            }
        },
        "mail_smtpsecure": "ssl"
    }
}

List of activated Apps

Enabled:
  - activity: 6.0.0-dev.0
  - app_api: 33.0.0
  - bruteforcesettings: 6.0.0-dev.0
  - calendar: 6.2.1
  - circles: 33.0.0
  - cloud_federation_api: 1.17.0
  - comments: 1.23.0
  - contacts: 8.4.1
  - contactsinteraction: 1.14.1
  - dashboard: 7.13.0
  - dav: 1.36.0
  - federatedfilesharing: 1.23.0
  - federation: 1.23.0
  - files: 2.5.0
  - files_downloadlimit: 5.1.0-dev.0
  - files_pdfviewer: 6.0.0-dev.0
  - files_reminders: 1.6.0
  - files_sharing: 1.25.2
  - files_trashbin: 1.23.0
  - files_versions: 1.26.0
  - firstrunwizard: 6.0.0-dev.0
  - guests: 4.6.0
  - logreader: 6.0.0
  - lookup_server_connector: 1.21.0
  - mail: 5.7.3
  - nextcloud_announcements: 5.0.0
  - notes: 4.13.0
  - notifications: 6.0.0
  - oauth2: 1.21.0
  - password_policy: 5.0.0-dev.0
  - photos: 6.0.0-dev.0
  - privacy: 5.0.0-dev.0
  - profile: 1.2.0
  - provisioning_api: 1.23.0
  - recommendations: 6.0.0-dev.0
  - related_resources: 4.0.0-dev.0
  - richdocuments: 10.1.0
  - richdocumentscode: 25.4.903
  - serverinfo: 5.0.0-dev.0
  - settings: 1.16.0
  - sharebymail: 1.23.0
  - spreed: 23.0.2
  - support: 5.0.0
  - survey_client: 5.0.0-dev.0
  - systemtags: 1.23.0
  - text: 7.0.0-dev.3
  - theming: 2.8.0
  - theming_customcss: 1.20.0
  - twofactor_backupcodes: 1.22.0
  - twofactor_totp: 15.0.0-dev.0
  - twofactor_webauthn: 2.6.0
  - updatenotification: 1.23.0
  - user_status: 1.13.0
  - viewer: 6.0.0-dev.0
  - webhook_listeners: 1.5.0
  - workflowengine: 2.15.0
Disabled:
  - admin_audit: 1.23.0
  - encryption: 2.21.0
  - files_accesscontrol: 4.0.0 (installed 4.0.0)
  - files_external: 1.25.1
  - suspicious_login: 11.0.0-dev.0
  - twofactor_nextcloud_notification: 7.0.0
  - user_ldap: 1.24.0
  - weather_status: 1.13.0 (installed 1.13.0)

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No specific log output is generated when this is happening – or not happening.

Additional info

I assume this is a bug. If this behavior is due a (mis-)configuration of Nextcloud on my side, please forgive me. Please tell me where to find the option I probably accidentally checked (or unchecked) somewhere in a place on the GUI unknown to me.

Thank you!