In NEXUS SRVMGR any attempt to set ACLs on shares does not work. This was
reported in a previous bug report. Volker said we should NOT fix it.
Use of SRVMGR in NT4 or MMC ComputerManagement Snap-In for WinXPPro also do NOT
work. Any attempt to set or change the share ACL results in a message: Access
To reproduce problem:
1) I am using tdbsam
2) groups are mapped so that the primary NT group is a Domain Admin
3) Domain Admin has root level priviledge on Unix
4) In MMC Go to:
Computer Management (Local) - right click on this
Select: Connect to another computer ...
Click the 'Another Computer' radio button
Clicking on the 'Advanced' tab, then on the 'Find Now' tab, does NOT locate
ANY samba servers - it used to!
Cancel out to the "Select Computer" dialog box, enter the PDC name in
Another Computer entry box, click OK
Left click to expand the 'System Tools' entry in left panel
Left click to expand the 'Shared Folders' entry in left panel
Click on Shares in left panel
Double click on a share in the right panel (you are logged on as root - right!)
Click on 'Share Permissions'
Change the permissions for Group Everyone in the 'Permissions for Everyone' box
"Shared Folders: Changes cannot be saved. Access is denied."
This was working in during alphas.
PS: This bug report is NEW - we now have NO way to set ACLs on Shares
If we elect to remove this facility it will be a reversion from Samba-2.2.x and
yet another migration problem for those wishing to upgrade.
Correction. I installed NT4Wks, SP6a. SrvMgr on it works OK.
I installed W2000 Pro and updated to latest service pack. MMC for Computer
Management will connect to Samba-3, and does allow Share ACLs to be set.
This would suggest that the problem is limited to XPPro and Nexus (on Win 9x/Me).
If we have to sacrifice anything here, I'd vote with Volker that we not fix it
for Nexus, but we do need this to work for XPPro, I will check this for Win
server 2003 as soon as I can - that way we will have a complete profile of what
works and what does not.
Ouch, the problem is that it does a setshareinfo on level 1005, which is about
various random bits such as DFS, client caching of the share namespace (not sure
exactly what that means), file-by-file integration, and disallowing forcible
Any suggestions on how we could support this? Returning unknown level also
causes the client to fail. I'm concerned that just saying "ok" will get us into
Hmm, how about if we decode it, and if no flags are being set, we return OK, but
if flags are being set, we return something bad...either INVALID_PARM or
Created attachment 41 [details]
Checks netsharesetinfo 1005 CSC settings to see if they match smb.conf
Should allow XP to set acls on shares now, as long as the user doesn't change
the client side cache policy settings.
jra has checked in my patch, so please test and let me know if this takes care
Confirmed FIXED - jht
originally reported against 3.0.0beta1. CLeaning out
non-production release versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.