Bug 2175385 - Cannot access Samba share with veto files = /.*/ [NEEDINFO]
Summary: Cannot access Samba share with veto files = /.*/
Keywords:
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: samba
Version: CentOS Stream
Hardware: x86_64
OS: All
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Andreas Schneider
QA Contact: Denis Karpelevich
URL:
Whiteboard: sync-to-jira review
Depends On:
Blocks: 2211605
TreeView+ depends on / blocked
 
Reported: 2023-03-04 09:57 UTC by Jared
Modified: 2023-07-17 18:33 UTC (History)
7 users (show)

Fixed In Version: samba-4.18.4-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2211605 (view as bug list)
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
Embargoed:
aboscatt: needinfo? (asn)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab samba-team samba merge_requests 3051 0 None closed Fix listing directories with `veto files = /.*/` 2023-04-20 08:24:44 UTC
Red Hat Issue Tracker RHELPLAN-150671 0 None None None 2023-03-04 09:57:59 UTC
Red Hat Issue Tracker SSSD-5774 0 None None None 2023-03-28 12:21:47 UTC
Samba Project 15360 0 None None None 2023-04-19 16:00:24 UTC

Description Jared 2023-03-04 09:57:04 UTC

Comment 1 Jared 2023-03-04 10:00:12 UTC
I think I messed up the initial post. So I'll add the information again.

Description of problem:
The whole Samba share is no longer accessible when "veto files = /.*/" is present in /etc/samba/smb.conf.

We're trying to hide dot files on Home Directory Samba Shares for Windows 10 users, even if the user has "Hidden items" enabled on File Explorer.

On a previous version of CentOS Stream release 8 with Samba 4.16.4-2 installed, this is no problem. However, upon upgrading Samba to 4.17.5-0, the Samba share is no longer accessible on either Windows or Linux using the same smb.conf file.

Version-Release number of selected component (if applicable):
samba-4.17.5-0.el8.x86_64

How reproducible:
We were able to reproduce it every time.

Steps to Reproduce:
1. Open "/etc/samba/smb.conf" in your text editor
2. Add "veto files = /.*/" under the [homes] section
3. Save the smb.conf file
4. Run "sudo systemctl restart smb"
5. Try to access the Home Directory Samba Share

Actual results:
Cannot access any Home Directory Samba Share at all. 

Expected results:
Can access a Home Directory Samba Share with all the dot files and folders being hidden.


Additional info:

sudo cat /etc/samba/smb.conf 
# See smb.conf.example for a more detailed config file or
# read the smb.conf manpage.
# Run 'testparm' to verify the config is correct after
# you modified it.
#
# Note:
# SMB1 is disabled by default. This means clients without support for SMB2 or
# SMB3 are no longer able to connect to smbd (by default).

[global]
        workgroup = SAMBA
        security = user

        passdb backend = tdbsam

        printing = cups
        printcap name = cups
        load printers = yes
        cups options = raw

        # Install samba-usershares package for support
        include = /etc/samba/usershares.conf

[homes]
        comment = Home Directories
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes
        veto files = /.*/

[printers]
        comment = All Printers
        path = /var/tmp
        printable = Yes
        create mask = 0600
        browseable = No

[print$]
        comment = Printer Drivers
        path = /var/lib/samba/drivers
        write list = @printadmin root
        force group = @printadmin
        create mask = 0664
        directory mask = 0775

Comment 2 Andreas Schneider 2023-03-28 12:23:07 UTC
Extend source3/script/tests/test_veto_files.sh

Comment 3 Andreas Schneider 2023-04-19 16:00:24 UTC
It fails because the "." and ".." directories matches '.*'.

Comment 6 Simon Wilson 2023-05-13 04:45:13 UTC
I just spent three hours trying to work out why my Samba shares stopped working. 

See https://bugzilla.samba.org/show_bug.cgi?id=15360 - this is a bug, and has been fixed upstream


Note You need to log in before you can comment on or make changes to this bug.