OS/2, eCS & ArcaOS - Technical > Networking

Samba Users and Groups

(1/7) > >>

Neil Waldhauer:
I'm running Samba server for OS/2 on ArcaOS 5.1. I am trying to understand how Users and Groups work, and also how the kLibc User Manager works along with Samba.

When ArcaOS 5.1 installs Samba, it makes a user named User, and password is Password. It also makes a password for the user I named during the install, Warp30. I don't know the password for this user, either.

The first time running Simple Samba Configuration Center (SSCC), the icon has the parameter /install. After that, the parameter is changed to /config. I'm not sure what actions /install takes. It takes a root password at that time.

It would be nice to be able to snapshot the users and groups, so that I could preserve a working set. It's too easy to make Samba stop functioning.

Ironically, I made a presentation on Samba at Warpstock 2015. I'm not sure how to get good information on the topic. I've somehow preserved my one working set of users since then, but I don't really understand in depth how to maintain users and groups.


Neil Waldhauer:
When I install samba, it makes some beeping noises. I now believe these noises signify the creation of exceptq Trap files. If I run smbpasswd.exe, it frequenly traps. Occasionally it works. I believe this is why it is difficult to get a set of working users and groups, which Samba needs to do its work.

Dave Yeo:
Need the libcx debug package and if available, the smpassw debug package, or debug build. Wild guess, an OOM (out of memory) issue triggering the sigtrap. Could be there to crash when a mal-formed password file is present or similar for security purposes.

Steven Levine:
I generally ignore exceptq reports generated without proper symbolics.  The exceptq documentation explains clearly what is required.

Also, by now it should be well known that when libcx0 traps it's common sense to look in %UNIXROOT/var/log/libcx in
case a libcx log was generated.

However, this libcx trap location is well known and the exceptq report happened to include a somewhat readable version of part of the log:

 0062F160 : 1E061F79 00000085 1E0625FC 1E061F8C : y........%......
 0062F170 : 0062F1CD 1E061F8C 00000000 0062F1EC : ..b...........b.
 0062F180 : 30303030 33616664 20313020 74727341 : 0000dfa3 01 Asrt
 0062F190 : 72777020 2E657469 33313A63 72703A33 :  pwrite.c:133:pr
 0062F1A0 : 5F646165 69727770 203A6574 65737341 : ead_pwrite: Asse
 0062F1B0 : 6F697472 6166206E 64656C69 7261203A : rtion failed: ar
 0062F1C0 : 3D3D2063 5F4F4E20 4F525245 36282052 : c == NO_ERROR (6
 0062F1D0 : 3D0A0A29 3D3D3D3D 42494C20 72207843 : )..===== LIBCx r

For some, as yet unknown reason, the mutex that serializes pread/pwrite operations has gone bad.

This smbpasswd.exe is a tad antique.  I recommend replacing it with one of Paul's new builds and see if this is sufficient to make the exception go away.

Rich Walsh:

--- Quote from: Steven Levine on January 15, 2024, 09:53:39 am ---by now it should be well known that when libcx0 traps it's common sense to look in %UNIXROOT/var/log/libcx in case a libcx log was generated.

--- End quote ---

"Common sense"? "well known"? Oh really... I guess you live in a different cave than I do because I have never once heard of this nor do I have a '%UNIXROOT/var/log/libcx' directory. Well, now I know. Thanks for sharing.

BTW... common sense has been shown to be a fallacy. It's what people who already know the answer say to those who don't. Stripped of their a priori knowledge, those who cite "common sense" usually prove every bit as clueless as the rest of us.


[0] Message Index

[#] Next page

Go to full version