Samba: 'Veto files' will hide all files no matter the share

[diamant-x]

Describe the issue you are experiencing

Hi,
I'm trying to veto all files from all shares but one within media.
However, anytime I put a * to choose any file it will hide ALL files from ALL shares.

Reported here as well:
https://community.home-assistant.io/t/custom-samba-share/612936/16?u=diamant-x

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Which add-on are you reporting an issue with?

Samba share

What is the version of the add-on?

12.3.1

Steps to reproduce the issue

1. Add as 'veto files' option: /ssl/*
2. bug occurs, all files, even those in other shares or without a path containing /ssl/ at all disappear and such shares won't allow to create files.

System Health information

System Information

version	core-2024.4.1
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.12.2
os_name	Linux
os_version	6.1.73-haos-raspi
arch	aarch64
timezone	Europe/Madrid
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
GitHub API Calls Remaining	5000
Installed Version	1.34.0
Stage	running
Available Repositories	1405
Downloaded Repositories	28

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 12.1
update_channel	stable
supervisor_version	supervisor-2024.03.1
agent_version	1.6.0
docker_version	24.0.7
disk_total	116.5 GB
disk_used	85.8 GB
healthy	true
supported	true
board	rpi4-64
supervisor_api	ok
version_api	ok
installed_addons	AdGuard Home (5.0.6), ESPHome (2024.3.1), FTP (5.0.2), Firefly iii (6.1.13), Firefly iii Data Importer (1.4.5), Home Assistant Google Drive Backup (0.112.1), InfluxDB2 (0.1.1), WireGuard (0.10.2), Nginx Proxy Manager (1.0.1), Samba share (12.3.1), Prowlarr NAS (nightly-1.16.0.4387-ls161), Vaultwarden (Bitwarden) (0.21.2), chrony (3.0.1), motionEye (0.20.0), qBittorrent (4.6.4), Sonarr (4.0.2.1408), Radarr (5.3.6.8612), Lidarr NAS (2.1.7.4030), Plex Media Server (3.5.0), MariaDB (2.6.1), Bazarr NAS (1.4.2), DOODS2 (1), Castsponsorskip (0.7.4), phpMyAdmin (0.9.1), Traccar (0.25.0), File editor (5.8.0)

Dashboards

dashboards	8
resources	18
views	18
mode	storage

Recorder

oldest_recorder_run	7 de febrero de 2024, 18:39
current_recorder_run	6 de abril de 2024, 08:28
estimated_db_size	4122.53 MiB
database_engine	mysql
database_version	10.6.12

Anything in the Supervisor logs that might be useful for us?

N/A

Anything in the add-on logs that might be useful for us?

N/A

Additional information

Expected result should be to only match such regex.

[diamant-x]

My gut feeling is that the 'backslash' icon is used in the system configuration file of smb to separate entries, so there should be some way to 'escape' the backslash when needed as part of filename veto.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[diamant-x]

Still an issue. So far I'm unaware of any changes being done on this addon to fix it.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[diamant-x]

Still an issue.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[diamant-x]

No updates have been pushed for this addon so still an issue.
I have since moved to implement Account permissions for my share and user specific to this purpose

[as-kholin]

I believe PR #3701 may address the issue behind the one you were calling out

The Veto Files section takes the list of 'vetoed' files - and then applies the same veto list to all paths - the PR instead gives radio buttons to enable/disable specific shares in the config (So, for the case mentioned, you would only need to veto files inside the share you expose).

Turning one off then removes the section that tells Samba that it should share that folder in the first place.

[as-kholin]

@diamant-x Wanted to get your feedback on this.

Per Sambas configuration for veto files, it cannot be used to veto directories listed as directories - it requires the use of Linux directory separators, and explicitly says you cannot include the '/' character in your file name - it only matches in-folder names.

See smb.conf documentation on Veto Files

Samba will let you hide subdirectories as if they are files. For example, (if the subdirectory is '/Media/hideme/', then Veto Files should allow you to hide the subdirectory by vetoing hideme or hide* in Veto Files. Using the wildcard example, hide* should hide a directory named hideme in any subfolder, a file named hidethisdoc, as well as a file 10 directories called hidesecrets - it does not care which folder it is in, it applies to any entry IN a folder that matches.

This also does not allow you to hide an entire top-level share (for HA, the list in the image from my previous comment), just the files/folders in it (And HA Samba Plugin only has one list of veto files, which it applies to all paths currently)

Unfortunately, Samba does not appear to have the inverse of Veto files, so there is no where to provide a list of 'only expose these files' - you have to list what not to expose.

---

With that basis - curious on your opinion on if PR #3701 (which allows the option to not expose entire shares) would meet the need you created this PR for ('Selectively enabling Shares' to hide the top level folders you do not want exposed - which Veto Files cannot do - and then within the one you do want exposed, veto files to hide files/subfolders).

If so, I will add the PR as a fix for this issue - but wanted to confirm with you, as the author, before doing so.

as-kholin

[diamant-x]

Tldr; it could be considered a fix, yes. Thanks.

My use case was meant to be able for another server, which is stuck in smb v1, to be able to write to a mounted folder (mounted from a non-v1 device) within media of my hassio. The issue then was that all HA shares were then exposed. This meant, among others, my SSL path would be mounted with a smb v1 connection, leaving it exposed to attack within my network. As a result I was trying to veto all files, from all other shares except one from within the media share. With your PR I should be able to do as you mention: only exposed the media, and veto all subdirectories except the one I want my "less secure device" to be able to see through samba.

Thanks!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[as-kholin]

Pending merge of #3701.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[diamant-x]

Please don't close, the Pull Request is in its final steps. :) #3701

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[diamant-x]

Please don't close, the Pull Request is in its final steps. :) #3701

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[diamant-x]

Still waiting for the outstanding pull request