Bug 4160 - VFS recycle settings forgotten on include
VFS recycle settings forgotten on include
Status: ASSIGNED
Product: Samba 3.0
Classification: Unclassified
Component: Config Files
3.0.23c
x86 Linux
: P3 normal
: none
Assigned To: Holger Hetterich
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-10 10:56 UTC by Andri
Modified: 2010-03-05 15:37 UTC (History)
4 users (show)

See Also:


Attachments
smb.conf (1.50 KB, text/plain)
2010-03-05 15:35 UTC, Holger Hetterich
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andri 2006-10-10 10:56:25 UTC
In an effort to selectively show shares to users (browseable) I've made smb.conf.%U files in which I set the browseable flag for shares that users can view. Works well, until I discovered it breaks the VFS recycle.

Shortened confs:
----------------
smb.conf:
[Share]
browseable = no
path = /share
valid users = user
vfs objects = recycle
        recycle:keeptree = true
        recycle:versions = true

[global]
include = /etc/samba/smb.conf.%U

smb.conf.user:
[Share]
browseable = yes

--
The problem is, that keeptree and versions settings are lost this way -- that is no versioning and no keep-tree. The new browseable flag, and other settings I've made (comment etc. before the include) seem to work/stay nicely.

Recycling is quite vital IMO, and selectively showing shares is also something I'd very-very much like to continue to use -- for overcoming the limited log-in capabilities of Windows.
Comment 1 Andri 2006-10-10 15:05:12 UTC
When the vfs objects section is duplicated to the user's smb.conf, recycle works.
So it'd be nice if the inheritance in include files would be either on by default or optional in the future -- manually copying the recycle section too all sub-confs would be pretty redundant.
Comment 2 Holger Hetterich 2010-02-26 13:22:55 UTC
And that's bad, right.

And if I think about modules like full audit or traffic analyzer, I
think it's particulary bad.

I took a sneak peek into the sources of master and I am almost sure
this doesn't work.

However let me first reproduce this just to make sure.

Stay tuned.
Comment 3 Holger Hetterich 2010-02-28 12:56:12 UTC
Sucessfully reproduced on master.
Comment 4 Holger Hetterich 2010-02-28 15:11:40 UTC
I am a bit on a dead end here. I am testing this using both the code and also check this via testparm.
Like in the initial report,
in my included file I have a "redefinition" of a share, and my expectation was
that the options there are inherited.

Testparm says:
Processing section "[pool]"
Processing section "[pool]"
indicating that it processes both service definitions.
However, in contrast to the initial report, the option I have set in the
included file:
"browseable = yes"
is ignored and not inherited when running testparm.

So I am currently not really sure what the planned behaviour should be.
Is this supposed to work at all?

As long as I am not sure of this, I have no pointer to deeper dig into
copy_service() and friends.

The initial problem is still there, the parametric options for a vfs module
are lost as soon as a service is redefined in an included file.
Comment 5 Volker Lendecke 2010-02-28 16:02:37 UTC
You might want to take a look at param/loadparm.c:6110ff. This seems to be intentional. Not sure what happens when this is removed.

Volker
Comment 6 Holger Hetterich 2010-03-05 15:32:49 UTC
This is confusing to me. My smb.conf has three service definitions, and the only service add_a_service is running through is "homes". Service "[tmp]" and "[pool]" don't seem to be involved with this function. Therefore I guess the removal of the lines Volker mentioned don't change anything.
Comment 7 Holger Hetterich 2010-03-05 15:35:21 UTC
Created attachment 5462 [details]
smb.conf
Comment 8 Holger Hetterich 2010-03-05 15:37:21 UTC
and /etc/samba/blah.conf is just:

[pool]
browseable = yes