Univention Bugzilla – Bug 30331
Control of share access via computer room module is not working properly (Samba4)
Last modified: 2019-02-05 21:26:26 CET
When trying to control the access to shares via the computer room, the access rights are not set properly. Probably a reload of the samba4 service is not enough. After a restart or a force-reload, the shares were adopted properly.
(In reply to comment #0) > When trying to control the access to shares via the computer room, the access > rights are not set properly. Probably a reload of the samba4 service is not > enough. After a restart or a force-reload, the shares were adopted properly. A restart is critical because file lockings may be lost.
Bug 30323 might point in the same direction.
Seems to also apply to printers.
(In reply to comment #1) > A restart is critical because file lockings may be lost. Sure. A reload worked for UCS 3.0, though.
I think this is a samba bug and should be fixed with a normal UCS errata update.
For me it worked like expected. When I change the permissions in UMC for a S4 share, the permissions are set after about 15 seconds. Maybe it is a school specific room problem?
In the test environment of the bug reporter initially there were some problems with the umask (Bug 30311), probably due to setting up UCS@school 3.1 using not the final version of the Setup-Wizzard. But even after fixing permissions and fixing samba4-idmap, the issue was reproducable: Adding and removing the Windows7-Client IP from the "hosts deny" line in /etc/samba/local.config.d/Marktplatz.local.config.conf does not immediately revoke/grant access to the share. What works: * Access denied > Access granted pkill -HUP -f /usr/sbin/smbd Access is granted Doen't work: * Access granted > User accessed share > Access denied pkill -HUP -f /usr/sbin/smbd Access is still granted samba4 reload and then "pkill -HUP" doesn't help either, nor does "smbcontrol smbd reload-config". Probably this is even not restricted to smbd processes running on a samba4-DC but applies also to samba3 systems. Probably it would be required to 1. kill all smbd processes listed by "smbstatus -pfn" that have a connection to an IP in any "hosts deny" list 2. kill -HUP all other smbd processes.
Created attachment 5093 [details] Sample script for reloading/killing smbds Maybe also the main smbd processes will have to get a kill -HUP as well. This is not part of the script as yet.
(In reply to comment #0) > When trying to control the access to shares via the computer room, the access > rights are not set properly. Probably a reload of the samba4 service is not > enough. After a restart or a force-reload, the shares were adopted properly. This is probably Bug #31141 (In reply to comment #7) > Probably it would be required to > > 1. kill all smbd processes listed by "smbstatus -pfn" that have a connection to > an IP in any "hosts deny" list The computerroom module does this already.
I had a samba4 environment with a winxp and a win8 client. With the default "access to shares" settings i was able to connect to all shares from both clients. Then i changed the settings to "only home" and access to class/marktplatz share was denied on both clients. Then i changed back to standard and was able to connect to the class/marktplatz share from winxp, but not from the win8 client. Access to the shares from win8 was only possible after a relogin.
(In reply to Felix Botner from comment #10) > I had a samba4 environment with a winxp and a win8 client. > > With the default "access to shares" settings i was able to connect to all > shares from both clients. Then i changed the settings to "only home" and > access to class/marktplatz share was denied on both clients. Then i changed > back to standard and was able to connect to the class/marktplatz share from > winxp, but not from the win8 client. Access to the shares from win8 was only > possible after a relogin. update: when changing share settings form "only home" to "all", win7 and win8 clients need some time (1-4 min), then access to non-home shares is possible again.
This issue has been filled against UCS@school 3.2. The maintenance with bug and security fixes for UCS@school 3.2 has ended on Dec 31, 2016. Customers still on UCS 3.x are encouraged to update to UCS 4.3 (or later). Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.