A Samba server is and ADS domain member and is administered using the Computer Manager. Setting of share permissions (share-level ACLs) fails due to lack of permission. I was also unable to set rights and privileges for the domain administrator (or anyone else for that matter). Attached are: 1) The smb.conf file 2) A tarball containing all the logs at loglevel 10 3) A wireshark capture of the entire process that failed
Created attachment 4556 [details] smb.conf file The Samba config file.
Created attachment 4557 [details] The Samba loglevel 10 log files in a tarball Tarball of loglevel 10 logs. The Windows XP workstation from which the admin was attempted is at IP 192.168.2.150 and its name is xptest. The Samba server is at IP 192.168.2.100 and its name is adsdms.
Created attachment 4558 [details] Wireshark Capture The wireshark capture of the failed attempt to set share-level ACLs.
To reproduce this problem: 1) Install the sample smb.conf.real file as smb.conf 2) Join the domain (succeeds): net ads join -Uadministrator%password 3) Start winbind and validate using: wbinfo -t (succeeds) 4) Start smbd 5) Edit /etc/nsswitch.conf as follows: passwd: files winbind shadow: files group: files winbind Go to the Windows XP Workstation. a) Login as the domain administrator. b) Open Explorer on Control Panel, select the advanced admin tools folder c) Double click on "Computer Management" d) Connect to another computer, enter the name adsdms as the computer name and click OK. e) Navigate down to Shares f) Right click on the clientdata folder and select "Properties" g) Click on the Share Permissions tab h) Remove the group "Everyone", add a domain user or group, then click Apply. Step (h) fails with the resulting logs submitted with this bug report.
I tried the same operation from a Windows XP Pro system on a Samba domain controller installation. This works without any problem. The problem is isolated to ADS domain member server installations. - John T.
Elevating severity level as I believe this one needs to be fixed for 3.4.1.
My guess is it's this problem: 1530 /* fail out now if you are not root and not a disk op */ 1531 1532 if ( p->server_info->utok.uid != sec_initial_uid() && !is_disk_op ) 1533 return WERR_ACCESS_DENIED; Does DOMAIN\Administrator have disk operator privileges on this machine ? Jeremy.
Disk Operator privilege was not available. The procedure for creating this privilege needs to be better documented. I will tend to that. The thing that threw this is the misleading error message. Lack of Disk Operator privilege should throw up a clear warning message that points to the solution. Thank you for helping to resolve this, but please can we provide more meaningful error reports. I will leave this bug open but reduce the severity.
Created attachment 4579 [details] Patch for 3.4.1. Patch for 3.4.1. Jeremy.
Re-assigning to Karolin for inclusion in 3.4.1. Jeremy.
FYI. Note for Karolin, everything worked after john gave the user SeDiskOperator privilege. Jeremy.
Okay, thanks. Patch will be included in 3.4.1. Closing out bug report.