Is that right? wbinfo/ getent

[ObiTobi]

Is that right? wbinfo/ get

I see e.g. with wbinfo - all users and groups from AD (Windows Server 2019) but not one computer account
Sometimes this seems to cause problems
The same with v13 and v12

 

[anodos]

Wbinfo and getent commands aren't designed to return computer accounts. What exact problems does this cause?

 

[ObiTobi]

[2023/01/01 00:03:25.653848, 0] ../../source3/smbd/service.c:169(chdir_current_service)
Jan 1 00:03:25 mynas001 1 2023-01-01T00:03:25.653914+01:00 mynas001.rjap.de smbd 32784 - - chdir_current_service: vfs_ChDir(/mnt/zpool02/backup/Windows) failed: Permission denied. Current token: uid=22603, gid=20515,

by v12 happens nothing( works grat) , but v13 is crashing

Code:

getfacl /mnt/zpool02/backup/Windows/
# file: /mnt/zpool02/backup/Windows/
# owner: backup
# group: windowssicherung
group:domänencomputer:r-x---a-R-c---:fd-----:allow
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:--------------:fd-----:allow

 

[ObiTobi]

No idea why Samba is misbehaving here? Or is there something wrong with my ACLs?

 

[anodos]

No idea why Samba is misbehaving here? Or is there something wrong with my ACLs?

If you're still seeing this: chdir_current_service then it's almost certainly the permissions on some path component leading to `/mnt/zpool02/backup/Windows/` e.g. /mnt/zpool02/backup.

 

[ObiTobi]

Interesting theory. I will test it. Even if I can not imagine it

 

[anodos]

Interesting theory. I will test it. Even if I can not imagine it

It's not that complex or surprising of a theory. Ability to chdir() into a path is controlled by the execute bit in Unix. Each path component is checked.

 

[ObiTobi]

It's not that complex or surprising of a theory. Ability to chdir() into a path is controlled by the execute bit in Unix. Each path component is checked.

Yes this is correct, but not the case here.

I found the groud.
All computers that cause problems for me have 2 network cards (WLAN and LAN).
If both cards are active and only the Ethernet adapter is connected, the error messages appear.
With version 12 it is just error messages without further effect. With version 13, a core dump is immediately created, which is a BUG. Even if Windows behaves incorrectly, this should not happen.
I have now created a script for the computers which automatically deactivates the WLAN interface when Eth is active and activates WLAN when Eth is not active. Here everything runs super clean with version 12. No more errors, everything is fine.
With version 13 it is not so. If the computer has had connection via LAN and some time later the same computer connects via WLAN it comes to a smbd.core.
It should be said that the error situation is always caused by the backup software (Macrium Reflect) which establishes another connection but with a different user than the one who is logged on to the machine.

I will occasionally test if the behavior has changed when new versions of TrueNAS Core 13 are released. Until then, I'll stick with version 12. It's not clear to me why TrueNAS is using the old Samba version where I think it's now 4.17, TrueNAS Core 13 is 4.15 which had a very short lifetime. (Maybe also because of such BUGS)


And by the way - if a backup is created with V12, the backup file has the correct permissions. If backup is created with v13 according to the rights are not set.

Code:

-rwxrwx---+ 1 backup  windowssicherung    316663876 Jan  4 11:01 0377501970220276-03-03.mrimg
-rw-r--r--+ 1 backup  windowssicherung    293610590 Jan  4 15:09 0377501970220276-04-04.mrimg

The first one is created with v12 and 2-nd with v13.