samba - Jul 2020 - Issues with FLOCK on NFS Share

Smb.conf:
[global]
       security = ADS
       workgroup = MUC
       realm = europe.bmw.corp
       netbios name = EDAINT
       netbios aliases = edaint.muc
       log file = /lfs/EDA/DATA/SOFTWARE/samba/var/log/samba/%m.log
       log level = 10
	
       # Default ID mapping configuration for local BUILTIN accounts
       # and groups on a domain member. The default (*) domain:
       # - must not overlap with any domain ID mapping configuration!
       # - must use a read-write-enabled back end, such as tdb.
       # - Adding just this is not enough
       # - You must set a DOMAIN backend configuration, see below
       idmap config * : backend = tdb
       idmap config * : range = 79846-100000
       idmap config MUC : backend = rid
 #      idmap config MUC : range = 79846-500000000
       template shell = /bin/bash
       template homedir = /home/%U
       winbind use default domain = true
       winbind offline logon = false
       winbind nss info = rfc2307
       winbind enum users = no
       winbind enum groups = no
       server string = EDA_Archiv_Integration
       username map=/lfs/EDA/DATA/SOFTWARE/samba/etc/usermap
       follow symlinks = yes
       wide links = yes
       unix extensions = no 
       unix charset = UTF-8
       kerberos method = secrets and keytab

#
[test]
    comment = EDA Archive Test
    directory = /lfs/EDA/DATA/SHARES/test/%U
    browseable = no
    writable = yes
    directory mask = 0700
    create mask = 0600
    force user = qqeda11
    force group = eda1
    kernel share modes = no
> Howdy!
>
> Am 6/30/20 um 2:37 PM schrieb Georg.Biberger--- via samba:
>> We are using Samba 4.10.16 as a readonly file server on a linux box
with SLES 12. All is working fine with our NAS NFS Shares. We are now trying to
integrate new NFS Shares from an archive provider. We have some problems with
samba not responding, when accessing files on these archive NFS shares.
>> We have done some Samba-Debugging and found out, that the call to flock
in source3/lib/system.c (kernel_flock) do not return and is blocking samba!
> kernel oplocks = no
>Only problem with that, it is the default setting :-(
> Can we see your smb.conf ?
Hi, 
I have now set 
kernel share modes = no
which solves this issue!
Attached my smb.conf.

I was wondering if the kernel_flock function in source3/lib/system.c is correct
implemented. E.g. when the function is called with parameter share_mode set to
FILE_SHARE_READ|FILE_SHARE_WRITE, then the function flock is not be called.
void kernel_flock(int fd, uint32_t share_mode, uint32_t access_mask)
{
#ifdef HAVE_KERNEL_SHARE_MODES
        int kernel_mode = 0;
        if (share_mode == FILE_SHARE_WRITE) {
                kernel_mode = LOCK_MAND|LOCK_WRITE;
        } else if (share_mode == FILE_SHARE_READ) {
                kernel_mode = LOCK_MAND|LOCK_READ;
        } else if (share_mode == FILE_SHARE_NONE) {
                kernel_mode = LOCK_MAND;
        }
        if (kernel_mode) {
                flock(fd, kernel_mode);
        }
#endif
        ;
}

Georg
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

On 01/07/2020 10:37, Georg.Biberger--- via samba wrote:
> Smb.conf:
> [global]
>         security = ADS
>         workgroup = MUC
>         realm = europe.bmw.corp
>         netbios name = EDAINT
>         netbios aliases = edaint.muc
>         log file = /lfs/EDA/DATA/SOFTWARE/samba/var/log/samba/%m.log
>         log level = 10
> 	
>         idmap config * : backend = tdb
>         idmap config * : range = 79846-100000
>         idmap config MUC : backend = rid
>   #      idmap config MUC : range = 79846-500000000
The 'idmap config' lines are borked, the default domain '*'
lines are
okay, but the 'MUC' domain lines are half correct, yes you can use the 
'rid' backend, but you must set a range. You did set a range, but it was
incorrect and you have commented it out. The two ranges must not 
overlap, but what you had before you commented it out, well, overlap 
would be an understatement, the '*' domain was totally inside the
'MUC'
domain, you need to fix this.

Rowland

>The 'idmap config' lines are borked, the default domain '*'
lines are
>okay, but the 'MUC' domain lines are half correct, yes you can use
the
>'rid' backend, but you must set a range. You did set a range, but it
was
>incorrect and you have commented it out. The two ranges must not 
>overlap, but what you had before you commented it out, well, overlap 
>would be an understatement, the '*' domain was totally inside the
'MUC'
>domain, you need to fix this.
I have the problem that all files on NFS-Shares are only accessible by the user
qqeda11 (unix-id 79846).
All users get mapped to qqeda11  with usermap qqeda11=*.
But the user qqeda11 is also known in the MUC-Domain as windows user
(muc/qqeda11 SID= S-1-5-21-43206524-2104247658-1151357142-1581344):

To achieve the correct mapping, I have added a mapping to winbindd_idmap.tdb:

	dumping id mapping from
/lfs/EDA/DATA/SOFTWARE/samba/var/locks/winbindd_idmap.tdb
	GID 79846 S-1-5-21-43206524-2104247658-1151357142-513
	USER HWM 79846
	UID 79846 S-1-5-21-43206524-2104247658-1151357142-1581344
	GID 79847 S-1-1-0
	GID 79848 S-1-5-2
	GROUP HWM 79849

Does this correspond with your explanation of id ranges?

Georg