Univention Bugzilla – Bug 50419
Share config entries created on the DC without the share was really created on memberserver
Last modified: 2019-10-29 20:24:32 CET
https://help.univention.com/t/shares-create-on-dc-don-t-not-configure-shares-on-member-server/13355/11 If share is not created on a memberserver due to access problems or entries in black- and/or whitelist, the configuration data will nevertheless be created on the DC. No feedback to the user.
Hello, can you provide more information: 1. Which UCS Version is your DC and your memberserver, including the erratum number? 2. Can you provide a UDM or LDAP dump of the share definition? udm shares/share list --position $dn_of_share univention-ldapsearch -b $dn_of_share 3. can you show your blacklist/whitelist UCR variable settings on the DC and on the memberserver? 4. Can you explain what you mean with configuration data? The /etc/samba/... configuration files?
1. UCS version 4.4-2 errata 319 2. output after share "otto1" was created on the DC and "/var" is not specified in the whitelist. DN: cn=otto1,cn=ucs-XXXX.my.domain.de,cn=shares,dc=my,dc=domain,dc=de directorymode: 0755 group: 5001 host: ucs-XXXX.my.domain.de name: otto1 owner: 0 path: /var/otto1 printablename: otto1 (ucs-XXXX.my.domain.de) root_squash: 1 sambaBlockSize: None sambaBlockingLocks: 1 sambaBrowseable: 1 sambaCreateMode: 0744 sambaCscPolicy: manual sambaDirectoryMode: 0755 sambaDirectorySecurityMode: 0777 sambaDosFilemode: 0 sambaFakeOplocks: 0 sambaForceCreateMode: 00 sambaForceDirectoryMode: 00 sambaForceDirectorySecurityMode: 00 sambaForceGroup: None sambaForceSecurityMode: 00 sambaForceUser: None sambaHideFiles: None sambaHideUnreadable: 0 sambaInheritAcls: 1 sambaInheritOwner: 0 sambaInheritPermissions: 0 sambaInvalidUsers: None sambaLevel2Oplocks: 1 sambaLocking: 1 sambaMSDFSRoot: 0 sambaName: otto1 sambaNtAclSupport: 1 sambaOplocks: 1 sambaPostexec: None sambaPreexec: None sambaPublic: 0 sambaSecurityMode: 0777 sambaStrictLocking: Auto sambaVFSObjects: None sambaValidUsers: None sambaWriteList: None sambaWriteable: 1 subtree_checking: 1 sync: sync writeable: 1 3. the new share should created in "/var". This dir wasn´t in the whitelist. That was the reason why a failure during the creating process occured 4. yes: share.conf + files in /etc/samba/share.conf.d In the above example the dir "otto1" was created on the memberserver as "root:nogroup" but no config entries and files in /etc/samba". On the DC, the UDM lead to believe the user an created error-free share.
The original post in the forum has more detail: =========================================================================== ucs version 4.4-2 errata 319 old shares are working but not new shares. Steps DC: configure a new share on the DC create share in container of the destination member server input global vars - no extra options and save new samba share is listed in the main share view Control Member Server: /etc/samba/shares.conf --> no include statement for the new share /etc/samba/shares.conf.d/ --> no config file for the new share (If both created manually shares are announced after smbd restart) If an existing share is modified on the DC, the changes are also not updated in the corresponding config files. =========================================================================== So I think the statement > configuration data will nevertheless be created on the DC. in the Bug description refers to the share object in LDAP and not to the actual Samba share cfg files. I had a quick look at univention.lib.listenerSharePath.createOrRename() and it looks like the code first creates the directory and then checks is_blacklisted(). If that returns True, the code stops and doesn't the desired permissions. I guess the samba-shares.py listener also bails out and doesn't write any share specfic file to shares.conf.d/. I don't remember if this was a deliberate design decision to create the directory before checking the blacklist, but it seems odd now.
The point > No feedback to the user. is a different story. The shares creation via UMC/UDM adds the shares/share type object to OpenLDAP, that object get's replicated to the target server, where a listener module (samba-shares.py) notices the necessity to create the share on that system. If something fails at that point, then there is no feedback mechanism currently back to the UMC/UDM. I'll have a look if we already have a feature request for that. A quick bugzilla search shows that the issue of this Bug is probably identical to what was reported as Bug 49771. *** This bug has been marked as a duplicate of bug 49771 ***