Bug 15255 - invisible but accessible shares from "included" config files using substitutions
Summary: invisible but accessible shares from "included" config files using substitutions
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.16.7
Hardware: All All
: P5 regression with 8 votes (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-29 10:51 UTC by Joerg Pulz
Modified: 2022-12-13 11:38 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joerg Pulz 2022-11-29 10:51:15 UTC
In our configuration we provide specific shares based on IP, username or primary group.
This is achieved by using substitutions with the following lines in smb.conf:

include = /path/to/smb.conf.%U
include = /path/to/smb.conf.%G
include = /path/to/smb.conf.%I

If a user "testuser" with primary group "testgroup" is connecting from "192.168.1.2" this would change dynamically to

include = /path/to/smb.conf.testuser
include = /path/to/smb.conf.testgroup
include = /path/to/smb.conf.192.168.1.2

Actually only one (/path/to/smb.conf.testgroup) of the named three files exists an contains a share definition:
[testshare]
   comment = Share for testing
   path = /testshare
   read only = yes
   public = no
   valid users = +testgroup

This was working fine in previous versions (up to 4.13.17). Connecting to the server using a Windows 7 or 10 machine there is one share "testshare" that is visible as share and also accessible.
Connecting using "smbclient -Utestuser -Lsambahost" resulted with correct share list:
Sharename       Type      Comment
---------       ----      -------
IPC$            IPC       IPC Service
testshare       Disk      Share for testing

Also "net share -Utestuser" gave correct results:
IPC$
testshare

After upgrading from 4.13.17 to 4.16.7 without any configuration change our results are different.

Connecting using a Windows 7 or 10 machine there is no share visible - Explorer just says "This folder is empty". But I can successfully connect to the share directly using \\sambahost\testshare\ - as long as I know the share name.
Connecting using "smbclient -Utestuser -Lsambahost" only shows:
Sharename       Type      Comment
---------       ----      -------
IPC$            IPC       IPC Service

Connecting using "smbclient -Utestuser \\\\sambahost\\testshare\\" works without problems.

Also "net share -Utestuser" shows only
IPC$

So it seems that substitution and parsing the resulting configuration file is working correctly, but somehow browsing for shares defined in such a way is broken as those are simply not showing up.
If I change the configuration from
include = /path/to/smb.conf.%G
to
include = /path/to/smb.conf.testgroup
the share is visible in Windows and using "net share" or "smbclient -L".

One strange thing to mention:
If I use "net share" in combination with "-mCORE", "-mCOREPLUS", "-mLANMAN1" or "-mLANMAN2" I get correct results every time but as soon as I use "-mNT1" or any higher protocol the share is not displayed.

Any ideas?
Comment 1 Arnaud FLORENT 2022-12-13 09:25:38 UTC
I'm also dealing with the same problem
Comment 2 Volker Lendecke 2022-12-13 11:06:58 UTC
Just to let you know: This issue happens because in Samba 4.16 the RPC services were taken out of smbd, the share listing is now done by a separate daemon. Unfortunately our internal configuration loading with all the macros is very difficult to replicate in this separate daemon. It will take days of work to get this straight again.
Comment 3 Arnaud FLORENT 2022-12-13 11:34:56 UTC
thanks Volker for your comment.

does this mean that this issue will not fixed?

do you think that "access based share enum" setting could and should be used instead?
Comment 4 Volker Lendecke 2022-12-13 11:38:50 UTC
(In reply to Arnaud FLORENT from comment #3)
> does this mean that this issue will not fixed?

Well, someone needs to fix it. Right now it is not my personal priority. If it is someone else's priority, I'm happy to give guidance how to fix it.

> do you think that "access based share enum" setting could and should be used
> instead?

Good question, haven't tried that. But I could imagine that this would work.