Allow to hide "hidden files" on public shares

[lucquer4]

This is a feature request:
Allow users to hide dot files on public shares, this could either be a per share config or a view option on the public share itself.

---

Original report:

⚠️ 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

Hidden files visibility can be configured through the gear icon, at user Files App. On public shared links, hidden files are always visible.
Few months ago I've had this issue also in Internal Links/User interface, in Grid Mode, but updating my Nextcloud system solved the issue.

Steps to reproduce

1. Make two copies of the same file in the same folder.
2. Rename one of them to start with a dot (Ex: file.txt > .file.txt)
3. File will be hidden (if users settings are configured accordingly)
4. Create a public link share.
5. Open public link in any browser.
6. Hidden file that you just created is visible through the public link.

Expected behavior

Hidden files should be hidden, specially in public links. It was working before in older versions of Nextcloud, then suddenly hidden files became visible in grid mode and public links, after an upgrade to 25, now after upgrading all the way to latest stable 27.0.0, hidden files are in fact hidden when user is logged in, list or grid mode, but hidden files are still visible in public links.

Installation method

Community Docker image

Nextcloud Server version

27

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Nginx

Database engine version

MariaDB

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

Upgraded to a MAJOR version (ex. 22 to 23)

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": {
        "memcache.local": "\\OC\\Memcache\\APCu",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379,
            "timeout": 0,
            "password": "***REMOVED SENSITIVE VALUE***"
        },
        "trusted_domains": [
            "base.laboratoriocisco.org",
            "192.168.10.195:444"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "27.0.0.8",
        "overwriteprotocol": "https",
        "overwitehost": "base.laboratoriocisco.org",
        "overwrite.cli.url": "https:\/\/base.laboratoriocisco.org\/",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "ssl",
        "mail_sendmailmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "default_phone_region": "BR",
        "maintenance": false,
        "theme": "",
        "loglevel": 0,
        "localstorage.allowsymlinks": true
    }
}

List of activated Apps

Enabled:
  - activity: 2.19.0
  - admin_audit: 1.17.0
  - bruteforcesettings: 2.7.0
  - calendar: 4.4.2
  - circles: 27.0.0
  - cloud_federation_api: 1.10.0
  - comments: 1.17.0
  - contacts: 5.3.2
  - contactsinteraction: 1.8.0
  - dashboard: 7.7.0
  - dav: 1.27.0
  - federatedfilesharing: 1.17.0
  - federation: 1.17.0
  - files: 1.22.0
  - files_external: 1.19.0
  - files_pdfviewer: 2.8.0
  - files_rightclick: 1.6.0
  - files_sharing: 1.19.0
  - files_trashbin: 1.17.0
  - files_versions: 1.20.0
  - files_zip: 1.4.0
  - fileslibreofficeedit: 1.1.0
  - firstrunwizard: 2.16.0
  - logreader: 2.12.0
  - lookup_server_connector: 1.15.0
  - mail: 3.2.2
  - nextcloud_announcements: 1.16.0
  - notes: 4.8.0
  - notifications: 2.15.0
  - oauth2: 1.15.0
  - password_policy: 1.17.0
  - photos: 2.3.0
  - privacy: 1.11.0
  - provisioning_api: 1.17.0
  - recommendations: 1.6.0
  - related_resources: 1.2.0
  - serverinfo: 1.17.0
  - settings: 1.9.0
  - sharebymail: 1.17.0
  - spreed: 17.0.1
  - support: 1.10.0
  - survey_client: 1.15.0
  - suspicious_login: 5.0.0
  - systemtags: 1.17.0
  - text: 3.8.0
  - theming: 2.2.0
  - twofactor_backupcodes: 1.16.0
  - twofactor_totp: 9.0.0
  - updatenotification: 1.17.0
  - user_status: 1.7.0
  - viewer: 2.1.0
  - weather_status: 1.7.0
  - workflowengine: 2.9.0
Disabled:
  - encryption: 2.15.0
  - files_accesscontrol: 1.17.0 (installed 1.17.0)
  - files_downloadactivity: 1.16.0 (installed 1.16.0)
  - ransomware_protection: 1.14.0 (installed 1.14.0)
  - user_ldap: 1.17.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No response

Additional info

No response

[szaimen]

cc @nextcloud/server-frontend

[histefanhere]

Just ran into this myself when setting up files to be shared with some clients, the Readme.md had an attatched image which auto generated an .attatchments.xxx folder. It was hidden by default for me, but through the share URL it's visible plain as day.

A workaround is to install the "Custom CSS" app and add the following rule:

#body-public tr.hidden-file { display: none !important; }

[lucquer4]

I can confirm that the workaround is effective. I just installed the Custom CSS app, added the rule, refreshed the page, and hidden files are no longer visible through public links.

However, if you download all files by clicking the icon in the right corner 'Download All Files', hidden files are still downloaded. It would be good if they could be ignored at all on public links, but it may not be possible to do this on the Nextcloud side. Therefore, I am working on a solution for the Apple side, as these hidden files seem to be generated only on Mac computers through Samba. MacOS generates a hidden file starting with ._ for every single file or folder copied, and the clients are getting confused by the name of the file. They can't recognize that the file has 4Kb and starts with "._". Since these files are not hidden in Windows, I always receive emails complaining about "The video is corrupted, is not playing, I can't open it."

For that matter, it would be nice to have a way to ignore those hidden files, if not every . file, maybe every ._ file, on the Nextcloud side, as they are rarely useful for the end user. One would be surprised by how all those simple computer tasks could be very non-obvious for most people.

About the "Hidden Files Bug" topic, I don't know if this is actually a Bug or if it's expected behavior, but this custom solution closes it for me. Thank you very much!

[landryb]

i think im also experiencing this after upgrading from 23 to 28, hidden files are shown in a public share.

tried forcing the user-setting show_hidden to 0 but that doesnt change anything. since the bug is still present, and a css workaround is... ugly, to say the least, could this bug be reopened ? thanks.

[landryb]

looking at other issues, its not fixed by #42023 which was in 28.0.0, and im on 28.0.3.

[susnux]

looking at other issues, its not fixed by #42023 which was in 28.0.0, and im on 28.0.3.

Public shares do not have a user so there is no way for a receiver to configure if they want to see dot files or not. So currently they are always shown.

[landryb]

looking at other issues, its not fixed by #42023 which was in 28.0.0, and im on 28.0.3.

Public shares do not have a user so there is no way for a receiver to configure if they want to see dot files or not. So currently they are always shown.

well, i beg to disagree, public shares are linked to the user creating the share, so imo it should obey that user setting wrt hidden files...

and i dunno if it was by accident, but on 23 it was working fine, ie hidden files/dotfiles weren't shown at all in a public share.

[susnux]

Yes but all files are shared with unknown users (public), when hiding there is no way for those users to enable "show hidden files".

[susnux]

But this is still not fixed or implemented, so reopen.

[landryb]

Yes but all files are shared with unknown users (public), when hiding there is no way for those users to enable "show hidden files".

i agree with you, but in that case i think it should obey the originating user setting, which might not want end users browsing his public share to see his hidden files he might have hidden on purpose. In my case, the hidden files feature is used via files_external app, using an NFS share where user 'hide' files this way, and they've been surprised to see hidden files in the public share..

I havent looked at the backend code sending the list of files in the public share, but to me the list should filter hidden files if the originating user has show_hidden to false, instead of having to hide them with css (and still have them downloadable via the zip feature)