Bug 15808 - The "copy" statement can only be used once and this prevents sophisticated configuration templates.
Summary: The "copy" statement can only be used once and this prevents sophisticated co...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.17.12
Hardware: x64 Linux
: P5 trivial (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-15 20:52 UTC by Wolfgang Rohm
Modified: 2025-02-16 01:03 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Rohm 2025-02-15 20:52:06 UTC
| Can't install the newest version to test.
 | Couldn't find any similar bug report.


Hello everyone.

I'm setting up a personal SAMBA configuration, but am prevented to "implement" a template driven configuration. This creates massive redundancy and quite frankly a miserable mess.

Although the "log.rpcd_classic" log file reports all "copy" statements with their corresponding share names, only _one_ is ever applied to the share service.

; [2025/02/14 13:35:36,  2] ../../source3/param/loadparm.c:2897(lp_do_section)
;   Processing section "[Share]"
; [2025/02/14 13:35:36,  3] ../../lib/param/loadparm.c:1152(handle_copy)
;   Copying service from service @TEMPLATEUSER
; [2025/02/14 13:35:36,  3] ../../lib/param/loadparm.c:1152(handle_copy)
;   Copying service from service @TEMPLATEFS

Curious is, that the order of declaration does NOT seem to be of importance. BUT it is NOT one of the templates itself, because they can be used alone and will be applied without any errors. I also changed the amount of templates, no difference. This is not a recursion problem, since the to be copied files do not include any copy statements.

I will update the bug report to include a sample configuration, as soon as i created it.
Comment 1 Wolfgang Rohm 2025-02-16 01:03:20 UTC
It seems like i DID make a mistake, since it seems to work as intended, now. My permission template hat "+&" instead of "@" in read/write users. I will test further later and close this bug accordingly.