[Samba] (no subject)
I'd like to raise the issue discussed in the thread below. I've faced exactly the same problem and came to exactly the same way out - shutdown winbindd and use "force unknown acl user".
We use "simple" mapping in the environment - all AD accounts have corresponding NIS accounts (the same name) and the mapping is being done by smbd.
The problem here is that I've got a problem with this - when just set up it works perfectly. But if I change primary GID of the user to another one (in this example - user1, old 38916 -> new 38901) I get the access denied error with the following in logs (level 10, some private data masked):
[2007/06/18 16:22:33, 5] smbd/posix_acls.c:unpack_nt_owners(919)
unpack_nt_owners: validating owner_sids.
[2007/06/18 16:22:33, 10] passdb/lookup_sid.c:sid_to_uid(407)
sid_to_uid: winbind lookup for non-local sid S-1-5-21-XXXXXXXXXX-XXXXXXXXX-XXXXXXXXXX-XXXXX failed
[2007/06/18 16:22:33, 3] passdb/lookup_sid.c:fetch_gid_from_cache(253)
fetch gid from cache 38916 -> S-1-5-21-273419216-XXXXXXXXX-XXXXXXXXXX-XXXXX
[2007/06/18 16:22:33, 5] smbd/posix_acls.c:unpack_nt_owners(962)
unpack_nt_owners: owner_sids validated.
[2007/06/18 16:22:33, 3] smbd/posix_acls.c:set_nt_acl(3134)
set_nt_acl: chown site/home/user1/test2. uid = 24983, gid = 38916.
[2007/06/18 16:22:33, 3] smbd/posix_acls.c:set_nt_acl(3138)
set_nt_acl: chown site/home/user1/test2, 24983, 38916 failed. Error = Operation not permitted.
[2007/06/18 16:22:33, 10] locking/locking.c:del_share_entry(658)
del_share_entry: num_share_modes = 1
[2007/06/18 16:22:33, 10] locking/locking.c:del_share_entry(663)
del_share_entry: deleted share_mode_entry: pid = 720, share_access = 0x7, private_options = 0x0, access_mask = 0x12008a,
port = 0x0, type= 0x0, file_id = 4, dev = 0x14, inode = 17667723
[2007/06/18 16:22:33, 10] locking/locking.c:del_share_entry(673)
del_share_entry: deleting entry 0
[2007/06/18 16:22:33, 10] locking/locking.c:del_share_entry(695)
del_share_entry: Remaining table.
[2007/06/18 16:22:33, 10] smbd/close.c:close_normal_file(203)
close_normal_file: share_entry_count = 0 for file home/user1/test2
[2007/06/18 16:22:33, 10] locking/posix.c:posix_locking_close_file(1249)
posix_locking_close_file: file home/user1/test2 has no outstanding locks.
[2007/06/18 16:22:33, 2] smbd/close.c:close_normal_file(270)
avteresc closed file home/user1/test2 (numopen=0)
[2007/06/18 16:22:33, 5] smbd/files.c:file_free(459)
freed files structure 4172 (0 used)
[2007/06/18 16:22:33, 3] smbd/error.c:error_packet(147)
error packet at smbd/nttrans.c(1422) cmd=160 (SMBnttrans) NT_STATUS_ACCESS_DENIED
I.e. at some stage of working on ACL Samba gets old GID from somewhere and tries to chown the file to it.
Samba version is 3.0.20b from SLES9SP3 (but tested on 3.0.25 with the same result).
Config file looks like this (again, some privates masked):
workgroup = LOCAL
realm = LOCAL.DOMAIN
server string = %L - Test Samba Server - %v
security = ADS
password server = dc.local.domain
username level = 2
lanman auth = No
log level = 10
syslog = 0
log file = /var/log/samba/smb.common.log
max log size = 100000
time server = Yes
deadtime = 15
socket options = IPTOS_LOWDELAY TCP_NODELAY
load printers = No
show add printer wizard = No
os level = 0
preferred master = No
local master = No
domain master = No
dns proxy = No
wins server = XX.XXX.X.XX, XXX.XX.X.XX
kernel oplocks = No
directory security mask = 01775
force unknown acl user = Yes
oplocks = No
level2 oplocks = No
comment = Home
path = /home/%S
valid users = %S
read only = No
inherit permissions = Yes
browseable = No
Upon the connection request, though, Samba recognizes the UID/new GID correctly, this strange glitch happens only at the moment of unpack_nt_owners. The file is being created with correct UID/new GID but with 0 size.
My guess this could be something related to caching, but I've restarted daemons, deleted some /var/lib/samba/*.tdb files related to winbindd with no dice. Reverting GID back resolves the problem.
Could someone give me some assistance with this?
>We have found a solution to our problem, although it is not ideal. We
>have used the "force unknown acl user" flag in the smb.conf file,
>setting it to "yes". We have used this at the moment as a quick fix to
>get around the problem, as we have not set up any authentication
>mechanism (winbind) within Samba.
>I'll send you the log file when I get a change to copy it over.
From: Jeremy Allison [mailto:jra at samba.org]
Sent: 24 March 2006 17:12
To: Bradford, Matthew
Cc: samba at lists.samba.org
Subject: Re: [Samba] SFU Permission Denied
On Fri, Mar 24, 2006 at 01:00:18PM -0000, Bradford, Matthew wrote:[color=blue]
> This appears to be an old problem, but is a complete show stopper for
> us at the moment.
> We are trying to access an NFS file system, via Samba, from a WinXP
> client. Within Windows itself everything is fine, but when accessing
> the shares from within an SFU cshell, an error is returned when a file[/color]
> is created. The file is successfully created, but a "Permission[/color]
> error is returned.
> We receive the "Unable to validate owner sid" message in the log file.
> Has any found a solution to this problem yet?
> We are using Samba 3.0.21c and SFU 3.5.[/color]
Debug level 10 log please ? I'm guessing that the problem might be the
uid/gid's on the file can't be looked up in the LSA. What
authentication/domain system are you using ?
To unsubscribe from this list go to the following URL and read the