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 Denied. 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 Click 'Apply' Error Message: "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 file deletion. 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 other trouble.
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 UNKNOWN_LEVEL ?
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 of it.
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.