Samba behaves different when client uses "sec=none" and when provides bad user (mapped to guest)

HI everyone.

I’ve been analyzing a problem with an embedded Linux/FPGA device that in some cases was failing to run properly when using files from a samba share. After some time I’ve found it is related to Samba bug 12783 and setting kernel oplocks on global fix the issue.

But while looking at that I have found a strange behavior I can’t understand. I have guest ok = yes on the share and map to guest = Bad User on global.

If I mount the share with a bad user, everything works OK and I can see the device lock on the file with smbstatus.

But if I mount the samba share with sec=none , the program will throw an error, I think because it wasn’t able to adquire a lock on the file - I don’t see a lock in smbstatus.

In both cases the connection is assigned to nobody, as configured for guest connections. I run samba 4.20.5 on Truenas Scale 24.10 . I sent this same information to the Samba mailing list and the answer was “Oh, yeah, somethings wrong, who knows if in Samba server, client, or Truenas” :man_shrugging:t2:

  • the output of testparm -s
Load smb config files from /etc/smb4.conf
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

Server role: ROLE_STANDALONE

# Global parameters
[global]
        bind interfaces only = Yes
        disable spoolss = Yes
        dns proxy = No
        load printers = No
        logging = file
        map to guest = Bad User
        max log size = 5120
        passdb backend = tdbsam:/var/run/samba-cache/private/passdb.tdb
        printcap name = /dev/null
        registry shares = Yes
        server multi channel support = No
        server string = TrueNAS Server
        winbind request timeout = 2
        workgroup = CORUSCANT
        idmap config * : range = 90000001 - 100000000
        fruit:zero_file_id = False
        fruit:nfs_aces = False
        idmap config * : backend = tdb
        create mask = 0664
        directory mask = 0775
        kernel oplocks = Yes


(REMOVED INFO FROM SHARES NOT INVOLVED IN THIS)

[descargas]
        ea support = No
        guest ok = Yes
        path = /mnt/NAS/descargas
        read only = No
        smbd max xattr size = 2097152
        vfs objects = streams_xattr shadow_copy_zfs ixnas zfs_core io_uring
        tn:vuid =
        fruit:time machine max size = 0
        fruit:time machine = False
        nfs4:chown = True
        tn:home = False
        tn:path_suffix =
        tn:purpose = MULTI_PROTOCOL_NFS

  • the audit logs provided by Truenas when I connect with bad user
Logon ID: '0'
Logon Type: 3
Local Address: ipv4:192.168.1.4:445
Remote Address: ipv4:192.168.1.100:55186
Service Description: SMB2
Auth Description: Null
Client Domain: ''
Client Account: badusertest
Workstation: ''
Became Account: Null
Became Domain: Null
Became Sid: Null
Mapped Account: badusertest
Mapped Domain: ''
Netlogon Computer: Null
Netlogon Trust Account: Null
Netlogon Negotiate Flags: '0x00000000'
Netlogon Secure Channel Type: 0
Netlogon Trust Account Sid: Null
Password Type: NTLMv2
Client Policy Access Check: Null
Server Policy Access Check: Null
Vers:
  Major: 0
  Minor: 1
Result:
  Type: NTSTATUS
  Value Raw: 3221225572
  Value Parsed: NT_STATUS_NO_SUCH_USER
  • the smbstatus when connected with bad user
Samba version 4.20.5-truenas
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
----------------------------------------------------------------------------------------------------------------------------------------
193273  nobody       nogroup      192.168.1.100 (ipv4:192.168.1.100:55188)  SMB3_11           -                    -
102411  nobody       nogroup      192.168.1.10 (ipv4:192.168.1.10:47964)    SMB3_11           -                    -

Service      pid     Machine       Connected at                     Encryption   Signing
---------------------------------------------------------------------------------------------
IPC$         102411  192.168.1.10  Fri Jan 17 18:53:13 2025 CET     -            -
descargas    193273  192.168.1.100 Fri Jan 17 21:56:27 2025 CET     -            -
Carpetas Personales 102411  192.168.1.10  Fri Jan 17 18:53:13 2025 CET     -            -
IPC$         193273  192.168.1.100 Fri Jan 17 21:56:27 2025 CET     -            -


Locked files:
Pid          User(ID)   DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
193273       65534      DENY_NONE  0x12019f    RDWR       BATCH            /mnt/NAS/descargas   MiSTer/games/AO486/media/another world/another world.vhd   Fri Jan 17 21:58:04 2025
  • the audit logs provided by Truenas when I connect with sec=none
Logon ID: '0'
Logon Type: 3
Local Address: ipv4:192.168.1.4:445
Remote Address: ipv4:192.168.1.100:43240
Service Description: SMB2
Auth Description: Null
Client Domain: ''
Client Account: ''
Workstation: ''
Became Account: nobody
Became Domain: TRUENAS
Became Sid: S-1-5-21-2028966449-1147323095-3560797536-501
Mapped Account: ''
Mapped Domain: ''
Netlogon Computer: Null
Netlogon Trust Account: Null
Netlogon Negotiate Flags: '0x00000000'
Netlogon Secure Channel Type: 0
Netlogon Trust Account Sid: Null
Password Type: No-Password
Client Policy Access Check: Null
Server Policy Access Check: Null
Vers:
  Major: 0
  Minor: 1
Result:
  Type: NTSTATUS
  Value Raw: 0
  Value Parsed: SUCCESS
  • the smbstatus when using sec=none
Samba version 4.20.5-truenas
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
----------------------------------------------------------------------------------------------------------------------------------------
102411  nobody       nogroup      192.168.1.10 (ipv4:192.168.1.10:47964)    SMB3_11           -                    -
187450  nobody       nogroup      192.168.1.100 (ipv4:192.168.1.100:43240)  SMB3_11           -                    -

Service      pid     Machine       Connected at                     Encryption   Signing
---------------------------------------------------------------------------------------------
IPC$         102411  192.168.1.10  Fri Jan 17 18:53:13 2025 CET     -            -
IPC$         187450  192.168.1.100 Fri Jan 17 21:44:41 2025 CET     -            -
Carpetas Personales 102411  192.168.1.10  Fri Jan 17 18:53:13 2025 CET     -            -
descargas    187450  192.168.1.100 Fri Jan 17 21:44:41 2025 CET     -            -

No locked files

Any idea what can be happening?

IIRC when you try to mount with sec=none it’s trying to perform an anonymous, which isn’t the same as a guest login attempt. That said, is it really that hard to use authentication? :slight_smile:

No, it is super easy, but I’m trying to figure out the impact that bug I mentioned before have in several scenarios, and this difference in the audit logs seemed like something to try to understand better to avoid reaching to wrong conclusions.

I just figured out that, whatever the difference is, it doesn’t have an impact: the different behavior I was observing was related to the original kernel oplocks bug. I will report in the Samba bugtracker and mailing list. But basically:

Kernel Oplockssec=nonebad user
NoOKOK
Yes (Share)NO OKNO OK
Yes (Global)OKOK
Yes (Global and Share)NO OKOK

TrueNAS Scale shares configured to both SMB and NFS enable Kernel Oplocks on the share, that is why I was affected by this in the first place.

If you have a reproducible bug against truenas you should file a bugticket in our jira so that we can fixit.

I can clearly reproduce, but after my last tests I don’t think this is a Truenas bug, I’m quite sure this is a Samba bug

Of course, if you still want me to open a bug on your tracker, I’ll gladly do it.

We can globally disable SMB2 leases if kernel oplocks are enabled at share level in TrueNAS. That’s probably more sensible solution than globally enabling kernel oplocks.

1 Like

OK, I will open a bug then. Thanks for the guidance!

Done

Thanks again for your support.

Thanks for the bug report. I’ll try to get changes into 25.04 BETA.