Bug 4709 - Creating file from SFU gives permission denied
Summary: Creating file from SFU gives permission denied
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.20b
Hardware: x86 Windows XP
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2007-06-19 03:16 UTC by Alexander
Modified: 2018-05-07 22:36 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexander 2007-06-19 03:16:09 UTC
Hello, this issue was raised at Samba maillist, but as no one replied and this looks like a bug - I'm submitting it here.
The problem is that despite winbindd is not running and force unknown acl user option is set - I get "Permission denied" message when creating a file. File itself is being created with correct permissions bu with 0 size. Please see details below and feel free to request any additional ones.

Hi list,

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[0]: 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)
  user1 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.

>>-----Original Message-----
>>From: Jeremy Allison [mailto:jra at samba.org] 
>>Sent: 24 March 2006 17:12
>>Subject: Re: [Samba] SFU Permission Denied

>>On Fri, Mar 24, 2006 at 01:00:18PM -0000, Bradford, Matthew wrote:
>>> 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

>>> is created. The file is successfully created, but a "Permission
>>> 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.

>>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 ?

Comment 1 Björn Jacke 2018-05-07 22:36:42 UTC
I don't think there is any issue with this in recent versions.