How to access Samba Logs to analyze W10 - Linux access issue

English Network/Internet
1

Hello Everyone,

Currently I am replacing a home server. Because of my positive experience with an earlier OpenSuse Linux version I stepped into Leap 15.4 for this new server. My initial demands for this server are basic. Remote access via VNC connection within the LAN (Yep, me graphical guy) and file sharing. I am quite fond of the VNC connection that starts with the inlog screen so two different users are able to log in.

I thought I was ready for starting using the server, the Samba configuration was kept minimal with only the lines I really could understand. And that Samba configuration was working against one W10 system. At the point I wanted to make its shares more meaningful I did not have access anymore (so before changing those shares). The windows system gave me an error like the one direct below:

https://tweakers.net/fotoalbum/image/gJGrG2sC8e1jT1DHPYbRpm9S.png

So around the 20th of August I got an issue with Samba. The error suggested a typical problem in the alignment of the user account in the Windows and Linux environment, or an mistake with the Workgroup. But I passed that point already, so in spite of my lack of Linux knowledge I was not convinced the error indeed was what it suggested to be.

After that I tried a lot. Varying the Samba configuration in the many ways I could find (User access, force user, Folder access and ownership). I like to work in a structured way. I do not have much Linux experience, but enough general computer trouble shooting experience, finding back your bread crumbs is important. During the tests I ran for that Samba connection I started to loose that structure and the discipline to write it all down. So I am loosing my bearings a bit how to proceed.

The first question you always ask people that start asking questions is “what do the Samba logs tell?”. At that point I was myself as well curious about those logs. Maybe a beginner thing, but I do not know how to access them.
I know they can be found in /var/log/samba.

When I access the folder as a user

cd samba
bash: cd: samba: Permission denied

That I can understand.
When I access the folder as a superuser I get

sudo cd samba
password for root: 
cd: command not found
"cd" is a shell built-in command, it cannot be run directly.
the -s option may be used to run a privileged shell.
the -D option may be used to run a command in a specific directory.

I thought I was doing something not right, but there could be other causes as well:
For a moment I thought maybe Samba is not logging by default, so I started to meddle with settings to pin it down:

  • log file = /var/log/samba/%m.log
  • log level = 2 winbind:5
  • local5.debug -/var/log/samba/audit.log
    (meddle while I now was trying commands I do not yet comprehend fully)
    But no difference in the behavior of the log folder.

Another cause I could think of was that Samba service was not logging while it was completely dysfunctional (chicken or the egg). The service in the Yast process overview did not give me this suggestion:

**Logs
**
https://tweakers.net/fotoalbum/image/W5hamWMJmfUFYdydJP6kgTYS.png

**Details
**

* smb.service - Samba SMB Daemon

       Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled)
       Active: active (running) since Fri 2022-09-09 20:27:07 CEST; 1h 36min ago
         Docs: man:smbd(8)
               man:samba(7)
               man:smb.conf(5)
      Process: 1891 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS)
     Main PID: 1895 (smbd)
       Status: "smbd: ready to serve connections..."
        Tasks: 4 (limit: 4915)
       CGroup: /system.slice/smb.service
               |-1895 /usr/sbin/smbd --foreground --no-process-group
               |-1898 /usr/sbin/smbd --foreground --no-process-group
               |-1899 /usr/sbin/smbd --foreground --no-process-group
               `-1900 /usr/lib64/samba/samba-bgqd --ready-signal-fd=47 --parent-watch-fd=13 --debuglevel=2 -F
    Sep 09 20:27:07 FS-002 systemd[1]: Starting Samba SMB Daemon...
  Sep 09 20:27:07 FS-002 smbd[1895]: [2022/09/09 20:27:07.444588,  0] ../../source3/smbd/server.c:1734(main)
  Sep 09 20:27:07 FS-002 smbd[1895]:   smbd version 4.15.8-git.500.d5910280cc7150400.3.11.1-SUSE-oS15.0-x86_64 started.
  Sep 09 20:27:07 FS-002 smbd[1895]:   Copyright Andrew Tridgell and the Samba Team 1992-2021
  Sep 09 20:27:07 FS-002 systemd[1]: Started Samba SMB Daemon.
  Sep 09 20:31:01 FS-002 smbd[2946]: [2022/09/09 20:31:01.988689,  0] ../../source3/smbd/process.c:345(read_packet_remainder)

But this information only tells the services runs and is started. Afaik it does not tell everything about the functioning of Samba itself and its communication.

I currently use:

  • openSUSE:Leap:15.4
  • Samba 4.15.8+git.500.d5910280cc7-150400.3.11.1

Can someone tell me how to get access to those log files?

2

So around the 20th of August I got an issue with Samba. The error suggested a typical problem in the alignment of the user account in the Windows and Linux environment, or an mistake with the Workgroup. But I passed that point already, so in spite of my lack of Linux knowledge I was not convinced the error indeed was what it suggested to be.

Workgroups are a historic conecept (unless using SMBv1).

Please start by showing us your working samba configuration (smb.conf) for the share(s) concerned.

3

See my advice here…
https://forums.opensuse.org/showthread.php/547219-smb-stopped-accepting-connections?p=2983177#post2983177

To watch the logging you do…

sudo tail -f /var/log/samba/log.smbd
4

@deano_ferrari
thank you for pointing me towards how to follow the log file. It logs quite elaborate:)

These logs give me some more input to investigate further.

I do not have the pretension not to have further questions to you people. I only need, and want, to know what to ask first.

So I investigate a little further to try to narrow this down

But already many thanks for me not flying blind anymore. I will keep you no matter what (for the sake of the forum input) posted.

5

Good. Let us know what you find.

I do not have the pretension not to have further questions to you people. I only need, and want, to know what to ask first.

So I investigate a little further to try to narrow this down

But already many thanks for me not flying blind anymore. I will keep you no matter what (for the sake of the forum input) posted.

Well, that’s the general idea to share information until the issue is resolved. :wink:

BTW, you didn’t show your working smb.conf as requested.

6

Hi deano_ferrari

to be honest I felt a bit reluctant to share the smb.conf file while it is a moving target.

I ran into issues with the access from W10 earlier, I did not get it working. After that I adopted the approach from https://www.youtube.com/watch?v=7Q0mnAT1MRg

In this approach the accessing users needed to be created in Linux, but in Linux only. The access via the Samba interface was taken care for by a system like user (smbuser, part of smbgroup).
So we as normal users were available as Linux users, and the samba shares could be accessed by the Linux access rights granted to the shares and their files.

Drawbacks from this approach were mentioned as well:

  • security leans full on the quality of the access rights set up in the Linux system
  • only one user is accessing the share folders and owns the files. This is a non-issue in user specific folders, but in folders with severasl users adding and changing files it can become unclear who has done what.

What I found positive about the approach it bypasses the issue of a named windows users (with an email address as an identity) accessing samba via their own identity. And moreover I got it working!

This approach broke down. Probably by something I did (no effect without a cause).

When I completed my setup for the vncviewer I noticed I had difficulties analyzing and updating in my Linux OS. In the Yast repository overview I saw repositories for Leap 15.1 to 15.4. The older repositories were causing the trouble. I cannot say I know how those older versions got in my installation. It was the first time I did actively looked at the repository management, it was a fresh install…

I removed al those older repositories openSUSE:Leap:15.x and openSUSE:Backports:SLE-15-SPx files. I cannot judge how but leaving from the timing this could have been a cause for my failing samba effect.

All right back to your question. I share two sets of code, the smb.conf and a partly shares.conf with two representative shares. The second set is the current test status, the moving target.
**
smbuser setup**
smb.conf

[global]
server string = FS-002
workgroup = THUIS
security = user
map to guest = Bad User
name resolve order = bcast host
include = /etc/samba/shares.conf

shares.conf

[media]
path = /store/media
force user = smbuser
force group = smbgroup
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
public = yes
writable = no

[administratie]
path = /store/administratie
force user = smbuser
force group = smbgroup
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
public = yes
writable = yes

The current files are testbed for experimenting:

[global]
server string = FS-002
workgroup = THUIS
security = user
map to guest = Bad User
#log file = /var/log/samba/%m.log
log level = 3
log level = 3 passdb:5 auth:5
#name resolve order = bcast host
include = /etc/samba/shares.conf

*shares.conf
*

[stash]
path = /stash
create mask = 0777
force create mode = 0777
directory mask = 0777
force directory mode = 0777
public = yes
writable = yes

This is were I am at the moment.

One thing perhaps, I installed (no standard software for OpenSuse) a wsdd service on the Linux server.

Installed Version
0.7.0-lp154.17.1
Fri 01 Jul 2022 04:47:47 PM CEST
Sun 10 Jul 2022 04:43:34 PM CEST
MIT
86.5 KiB
0 B
network / 15.4
obs://build.opensuse.org/network
https://www.suse.com/
noarch
lamb26
https://github.com/christgau/wsdd
wsdd-0.7.0-lp154.17.1
0

Best regards,

Ferd.

7

Actually, there is an openSUSE package available via the network repo.

8

Just in case these are of value…
https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Standalone_Server
https://wpguru.co.uk/2021/01/linux-windows-samba/

9

In this approach the accessing users needed to be created in Linux, but in Linux only. The access via the Samba interface was taken care for by a system like user (smbuser, part of smbgroup).
So we as normal users were available as Linux users, and the samba shares could be accessed by the Linux access rights granted to the shares and their files.

Since you’re aiming to have Windows 10 users access the Linux shares as guests, then you may need to check that it hasn’t been disabled on the client hosts. Here’s a nice blog on the subject that illustrates…

In particular, check the section “But what about guest access from non-AD machines?” in case that applies to your situation.

10

Hi deano_ferrari

at last some opportunity to test. Thanks for your links in your last two posts. Especially the last link (https://www.claudiokuenzler.com/blog…nd-event-31017) seems to be elaborate. I like the effort he puts in explaining the why behind certain options/settings.

In spite of this, like a typical technician I already had started my test sequence before reading anything:shame:, though the link mentioned explained a bit what I experienced. Before proceeding, the situation described is only created for the sake of testing. Having the same password everywhere is not my ideal world, But I wanted to rule out this aspect in this way.

First I did analyze the log I exported last weekend. This proofed much to long with a repetition of the same sections. Besides this it became impossible to related to the action in the W10 system

That is why I’ve done some testing again, now with tailing the resulting logging after each action in W10. Look below for the given situation.

  • Current smb.conf and shares.conf are already shared
  • Workgroup: THUIS
  • Non AD network
  • The w10 system, DESKTOPFERD2015, is a W10 Pro version, with the guest access restriction in place (which I prefer to keep that way)
  • The shares are created in the root level of the Linux System (FS-002). Of them the stash is relevant for this test and only intended for testing purposes.

ferd@FS-002:~> cd /
ferd@FS-002:/> ls -al
total 16
...]
drwxrwxrwx   1 ferd    users       0 Aug 28 15:16 stash
drwxrwxr-x   1 smbuser smbgroup   76 Aug 21 15:12 store
...]
ferd@FS-002:/>
  • The stash is set completely open and put on my (ferd) ownership.
  • Current password setup:
    [LIST]
  • Windows OS account , passwd_x
  • Windows credential against server FS-002: DESKTOPFERD2015\ferd, passwd_x
  • Linux OS user account: ferd, passwd_x
  • Samba user: ferd, passwd_x (for certainty this password was re-initiated this test session)

[/LIST]

The way it is now set up, with an entry in the credential manager I need to access the shared folder with logging in. I tried different approaches to test what could work. After each try the smb log were obtained:

logged in with credential ferd@W10desktop
DESKTOPFERD2015\ferd - not successfull

Result in smb log:


ferd@FS-002:~> sudo tail -f /var/log/samba/log.smbd
[sudo] password for root: 
[2022/09/17 17:14:53.781531,  5] ../../auth/gensec/gensec.c:543(gensec_update_done)
  gensec_update_done: ntlmssp[0x557ff234eae0]: NT_STATUS_WRONG_PASSWORD
[2022/09/17 17:14:53.781562,  3] ../../auth/gensec/spnego.c:1445(gensec_spnego_server_negTokenTarg_step)
  gensec_spnego_server_negTokenTarg_step: SPNEGO(ntlmssp) login failed: NT_STATUS_WRONG_PASSWORD
[2022/09/17 17:14:53.781591,  5] ../../auth/gensec/gensec.c:543(gensec_update_done)
  gensec_update_done: spnego[0x557ff233a7e0]: NT_STATUS_WRONG_PASSWORD
[2022/09/17 17:14:53.781652,  3] ../../source3/smbd/smb2_server.c:3955(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_LOGON_FAILURE] || at ../../source3/smbd/smb2_sesssetup.c:147
[2022/09/17 17:14:53.782632,  3] ../../source3/smbd/server_exit.c:240(exit_server_common)
  Server exit (NT_STATUS_CONNECTION_RESET)

**logged in with THUIS\ferd
**but making mistake with entering ferd huis - in spite of this eventually “successfull”
Result in smb log:

:
...]
[2022/09/17 17:22:49.539818,  3] ../../source3/auth/auth.c:202(auth_check_ntlm_password)
  check_ntlm_password:  Checking password for unmapped user [ferd]\[thuis]@[DESKTOPFERD2015] with the new password interface
[2022/09/17 17:22:49.539852,  3] ../../source3/auth/auth.c:205(auth_check_ntlm_password)
  check_ntlm_password:  mapped user is: [ferd]\[thuis]@[DESKTOPFERD2015]
[2022/09/17 17:22:49.539938,  5] ../../source3/passdb/pdb_tdb.c:602(tdbsam_getsampwnam)
  pdb_getsampwnam (TDB): error fetching database.
   Key: USER_thuis
[2022/09/17 17:22:49.540028,  3] ../../source3/auth/check_samsec.c:399(check_sam_security)
  check_sam_security: Couldn't find user 'thuis' in passdb.
[2022/09/17 17:22:49.540080,  5] ../../source3/auth/auth.c:264(auth_check_ntlm_password)
  auth_check_ntlm_password: sam_ignoredomain authentication for user [thuis] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
[2022/09/17 17:22:49.540141,  2] ../../source3/auth/auth.c:348(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [thuis] -> [thuis] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
[2022/09/17 17:22:49.540213,  2] ../../auth/auth_log.c:665(log_authentication_event_human_readable)
  Auth: [SMB2,(null)] user [ferd]\[thuis] at [Sat, 17 Sep 2022 17:22:49.540179 CEST] with [NTLMv1] status [NT_STATUS_NO_SUCH_USER] workstation [DESKTOPFERD2015] remote host [ipv6:xxxx] mapped to [ferd]\[thuis]. local host [ipv6:xxxx] 
  {"timestamp": "2022-09-17T17:22:49.540397+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4625, "logonId": "0", "logonType": 3, "status": "NT_STATUS_NO_SUCH_USER", "localAddress": "xxxx", "remoteAddress": "xxxx", "serviceDescription": "SMB2", "authDescription": null, "clientDomain": "ferd", "clientAccount": "thuis", "workstation": "DESKTOPFERD2015", "becameAccount": null, "becameDomain": null, "becameSid": null, "mappedAccount": "thuis", "mappedDomain": "ferd", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv1", "duration": 2853}}
[2022/09/17 17:22:49.540548,  3] ../../source3/auth/auth_util.c:2310(do_map_to_guest_server_info)
  No such user thuis [ferd] - using guest account
...]
[2022/09/17 17:23:28.356036,  3] ../../source3/smbd/smb2_server.c:3955(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_NOT_FOUND] || at ../../source3/smbd/smb2_ioctl.c:353
[2022/09/17 17:23:28.356906,  3] ../../lib/util/access.c:372(allow_access)
  Allowed connection from xxxx (xxxx)
[2022/09/17 17:23:28.357065,  3] ../../source3/smbd/service.c:611(make_connection_snum)
  make_connection_snum: Connect path is '/stash' for service [stash]
[2022/09/17 17:23:28.357168,  3] ../../source3/smbd/vfs.c:115(vfs_init_default)
  Initialising default vfs hooks
[2022/09/17 17:23:28.357211,  3] ../../source3/smbd/vfs.c:141(vfs_init_custom)
  Initialising custom vfs hooks from /[Default VFS]/]
[2022/09/17 17:23:28.357509,  2] ../../source3/smbd/service.c:854(make_connection_snum)
  desktopferd2015 (ipv6:xxxx) connect to service stash initially as user nobody (uid=65534, gid=65534) (pid 3069)
[2022/09/17 17:23:38.932871,  2] ../../source3/smbd/service.c:1129(close_cnum)
  desktopferd2015 (ipv6:xxxx) closed connection to service stash

Somehow, in spite of wrong entry got access to the folder. Making this a sort of “**** the system” approach.

Double clicked it to open it:
https://tweakers.net/fotoalbum/image/I8YdUacIqCu6qLCDxKQawri9.png

But I did not have permission to access, repeating the error of last time:
https://tweakers.net/fotoalbum/image/gJGrG2sC8e1jT1DHPYbRpm9S.png

In the smb

log the following was shown:

[2022/09/17 17:25:28.986585, 3] …/…/lib/util/access.c:372(allow_access)
Allowed connection from xxxx (xxxx)
[2022/09/17 17:25:28.986750, 3] …/…/source3/smbd/service.c:611(make_connection_snum)
make_connection_snum: Connect path is ‘/stash’ for service [stash]
[2022/09/17 17:25:28.986838, 3] …/…/source3/smbd/vfs.c:115(vfs_init_default)
Initialising default vfs hooks
[2022/09/17 17:25:28.986880, 3] …/…/source3/smbd/vfs.c:141(vfs_init_custom)
Initialising custom vfs hooks from /[Default VFS]/]
[2022/09/17 17:25:28.987070, 2] …/…/source3/smbd/service.c:854(make_connection_snum)
desktopferd2015 (ipv6:xxxx) connect to service stash initially as user nobody (uid=65534, gid=65534) (pid 3069)
[2022/09/17 17:25:28.991049, 5] …/…/source3/auth/auth.c:566(make_auth3_context_for_ntlm)
make_auth3_context_for_ntlm: Making default auth method list for server role = ‘standalone server’, encrypt passwords = yes
…]
[2022/09/17 17:25:28.994917, 3] …/…/source3/smbd/smb2_server.c:3955(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_FS_DRIVER_REQUIRED] || at …/…/source3/smbd/smb2_ioctl.c:353
…]
[2022/09/17 17:25:29.195368, 3] …/…/source3/smbd/filename.c:1559(get_real_filename_full_scan)
scan dir didn’t open dir .]
…]
[2022/09/17 17:25:29.196151, 3] …/…/source3/smbd/smb2_server.c:3955(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at …/…/source3/smbd/smb2_create.c:337



 
Googling on the string * smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED]

*https://serverfault.com/questions/900440/samba-configuration-statusnt-status-access-denied gave me a working approach to deal with this issue:



  - In a command prompt on the W10 platform a net use * /delete was executed (that *&^^%^$ windows registry): 


[INDENT=2]

Microsoft Windows [Version 10.0.19043.2006]
(c) Microsoft Corporation. All rights reserved.

C:\Users\Ferdinand>net use * /delete
You have these remote connections:

                \\Fs-002\stash
                \\fs-002\IPC$

Continuing will cancel the connections.

Do you want to continue this operation? (Y/N) [N]: y
The command completed successfully.


[/INDENT]



  - in the smb.conf the entry *passdb backend = smbpasswd*
 was added (and after that a restart of the smb process) 

[INDENT=2]

global]

server string = FS-002
workgroup = THUIS
security = user
map to guest = Bad User
passdb backend = smbpasswd
#log file = /var/log/samba/%m.log
log level = 3
log level = 3 passdb:5 auth:5
#name resolve order = bcast hostinclude = /etc/samba/shares.conf


[/INDENT]
[INDENT=3]
[/INDENT]
 These two steps resulted in me being able to access the folder. This made me quite positive, while being able to uberhaupt create a cause-effect.
Still a moving target though:


  - I expect I can go back to the desired linux accesses I had in mind. 
  - not so glad with having to log in to access the remote share (the cretential stuff) and with the credential stuff no matter what. My vulnerable password in that credential database. I suppose I should try to arrange things at the linux side by the 
  - But: I can now conclude the access to the folder is an independent mechanism of that of the credential mechanism. 
  - This is a user specific access (suppose). Still need to test I this access can work for a two user approach I expect the force user 
  - A question from my side concering the *But what about guest access from non-AD machines?*
 section of the https://www.claudiokuenzler.com/blog/879/windows-10-server-2016-access-samba-share-guest-account-analysis-workaround-event-31017 source: isn't this as unsecure as grant access to all guests in the W10 pro manchine? Do not understand the repercussions of map to guest = bad password fully. 


These are my findings until now. Tomorrow I hope to do some further steps, and look more into your sources.

Thanks for your effort,

Ferd
11

Yes, guest access is about convenience (unauthenticated access), and is not secure.

Using

map to guest = Bad User

mans that user logins with an invalid password are rejected, unless the username does not exist, in which case it is treated as a guest login and mapped into the guest account. Refer ‘man smb.conf’ for more options.

These are my findings until now. Tomorrow I hope to do some further steps, and look more into your sources.

Thanks for your effort,

Ferd

Ok, good luck with your samba tweaking. (More than I can keep up with.) :wink:

12

Still walking on…

In the weekend I got access on the /stash share. that was encouraging. Sadly none of the other shares offered the same access.
I found this a strange issue by the way, mostly it is complete access or no access at all.

To make a good comparison I created an identical share (/ferd2) as the /stash share. Access and SMB role from both were identical. This second share was not accessible (no surprise).

Not understanding this anymore I compared the logs today when accessing both shares. The result was a bit sobering.

In the communication I found out that the /stash share somehow was made a $IPC share. An anonymous access share. How this happened on the W10 side (my interpretation) is still a riddle for me (and I am not asking you all :wink: for answering it)

I saw it passing by during what I read as the initialization of the shares in the log:

  lp_load_ex: refreshing parameters
[2022/09/19 19:40:34.715184,  3] ../../source3/param/loadparm.c:557(init_globals)
  Initialising global parameters
[2022/09/19 19:40:34.715368,  3] ../../source3/param/loadparm.c:2873(lp_do_section)
  Processing section "[global]"
[2022/09/19 19:40:34.715586,  2] ../../source3/param/loadparm.c:2890(lp_do_section)
  Processing section "[media]"
[2022/09/19 19:40:34.715742,  2] ../../source3/param/loadparm.c:2890(lp_do_section)
  Processing section "[administratie]"
[2022/09/19 19:40:34.715901,  2] ../../source3/param/loadparm.c:2890(lp_do_section)
  Processing section "[installatie]"
[2022/09/19 19:40:34.716189,  2] ../../source3/param/loadparm.c:2890(lp_do_section)
  Processing section "[ferd]"
[2022/09/19 19:40:34.716364,  2] ../../source3/param/loadparm.c:2890(lp_do_section)
  Processing section "[ferd2]"
[2022/09/19 19:40:34.716493,  2] ../../source3/param/loadparm.c:2890(lp_do_section)
  Processing section "[stash]"
[2022/09/19 19:40:34.716647,  3] ../../source3/param/loadparm.c:1674(lp_add_ipc)
  adding IPC service

So this makes the stash share the issue, instead of the others.

I am looking now into username mapping to offer Samba a relation between the Windows account (often an email address) and the samba/Linux account. I saw this in the source https://www.claudiokuenzler.com/blog/879/windows-10-server-2016-access-samba-share-guest-account-analysis-workaround-event-31017 that was suggested to me in this topic. In that source it only was mentioned as approach for Active Domain solutions. From other sites I get the suggestion it is not only specific for AD.

Not much progress so far, though a bit more insight.

Regards to all.

13

Hello to you all,

A small update of my progress in getting access to my Leap 15.4 Fileserver.

Please interpret the global section of my smb.conf as a moving target.

[global]
client use spnego = no
server string = FS-002
workgroup = THUIS
security = user
map to guest = Bad User
passdb backend = smbpasswd
#log file = /var/log/samba/%m.log
log level = 3
log level = 3 passdb:5 auth:5
idmap config THUIS : backend = rid
idmap config THUIS : range = 10000 - 50000
idmap config * : backend = tdb
idmap config * : range = 1000 - 9999
#name resolve order = bcast host
include = /etc/samba/shares.conf

With the *client use spnego = no *setting i was able to open my share in the file server again. It prevents this error:
https://tweakers.net/fotoalbum/image/gJGrG2sC8e1jT1DHPYbRpm9S.png

A warning for other users: this setting seems already deprecated, so this solution is not future proof.
That the setting has an effect though is information as well.

Shares made fully accessible (like fragment direct below from shares.conf) are now readable and writable:

[ferd2]
path = /ferd2
create mask = 0777
force create mode = 0777
directory mask = 0777
force directory mode = 0777
public = yes
writable = yes

But I am still not recognized as a user on the Linux system. The share as direct below I can read, but not write:

[installatie]
path = /store/installatie
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
public = yes
writable = yes

So I am still not known as a recognized user on the Leap server.
Now working on idmap conf to see if I can map windows account against a Linux account.
For this I activated the winbind service on the Leap server.

I was last weekend busy with this. What I can remember, the idmap has several operation-modi to choose from.
The modus now used in the smb.conf (IDMAP_RID) is not the correct one for a stanalone server.

The most simple approach that is without Microsoft AD doable for a home server user is using standard Winbind TBD.
But to be honest I hardly know what I am talking about.

Having Access I now investigate that Winbind TBD mechanism to see if that can help me.

14

Strange. I haven’t needed to do that with my Linux shares with respect to Windows 10 client access. I’m not doing anything other than accessing the shares as the same samba user as per my existing Linux user(s).

15

I do not have the opportunity to put daily effort in in this issue (more realistic ~once a week), but I drag it along for a few months now. It feels like bad dream to be honest. Just have a functioning file server should not be rocket science.

I did not expect it would take so much effort to get it working. To nuance this I have to say that:

  • I am now more keen on the security side. The intended use of our new Linux server is 24/7 file sharing. The former server was merely a backup server that was online now and them.
  • I am a bit above my leaque in working with user mappings between Windows 10 and Linux. Large part of the effort goes to learning this. And I am not yet there:shame:.
  • The large intervals between the moments I can work on it do not help keeping track of what I have changed. Though I counter that with logging as much as possible.
  • A pre: I have got quite some routine in using Linux by now, knowing paths without having to look them up.

As far as I can gather it the difficulty lies in the fact I want to be able to use a Microsoft account (with user ID = email address) to access the Linux environment as a known user. This is a thing while an email address does not apply as candidate for a Linux account. I can imagine when Linux is your most important environment, and you have W10 along side for the odd jobs you can’t get around Windows yet you use a local account in windows. With a local account you have much more freedom to align W10 and Linux accounts with each other. Maybe you use a local account that makes live easy?

For security sake I want Linux to recognize me as a user of our local network. For this I still make use of the Workgroup identity as a common denominator both W10 and Linux can recognize.

Currently I am busy with configuring a name service switch as explained in https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member#Configuring_the_Name_Service_SwitchAdded the winbind service along the way. Just to try to find another approach, though it makes the equation not less complicated.
Not sure however if a Workgroup identity can be used as a domain definition at all. I do not have access at all to the server. And Winbindd does not give back “THUIS” is recognized. Barking up the wrong tree I fear. I am not even going to ask questions about this.

Back to an approach that at least did work in a way. Try to translate the windows passwds into samba accounts…
https://docs.oracle.com/cd/E37670_01/E41138/html/ol_standalone_samba.html