Bug #14322


Remote OmniOS SMB user/group management via Windows computermanagement not working

Added by Guenther Alka almost 2 years ago. Updated 12 months ago.

cifs - CIFS server and client
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


I have problems using Windows computermanagement to edit groups and users remotely.
What I have done (current Windows 10 Pro, OmniOS 151038 lts, 151040)

1. On OmniOS I added root to SMB group administrators

2.) Then I mapped a shared filesysem ex to z: as user root with the option "different user" and save pw
user: OmniOS-ip\root

3. I started Computermanagent on Windows.
With a mouse right-click on Computermanagement I connected the ip of OmniOS

i got an error that the computer could not be connected.
After I retried, it worked.

4. I was able to list/add/rename groups.
When I tried to add members via advanced > search, i got a login screen where I readded root credidentials, but no success (no users listed, only groups)

5. I was able to list users but could not add or rename.

As remote computermagent is the main method for local SMB server management this should work



computermanagement.png (40.1 KB) computermanagement.png Guenther Alka, 2022-12-08 04:46 PM
createuser.png (51.3 KB) createuser.png Guenther Alka, 2022-12-08 04:56 PM
Actions #1

Updated by Gordon Ross almost 2 years ago

  • Category set to cifs - CIFS server and client
Actions #2

Updated by Gordon Ross almost 2 years ago

If you're doing this from a Windows client, you need to use some care about which identity will be used to connect to the SMB server. Windows can be a bit surprising here, not necessarily using the identity you might think it should. You can confirm that with a quick "mdb -k" session (use "::smblist" and look at who is really connected).

Cautions: When you're logged onto a Windows client that's a domain member, the client appears to always try your domain account first when connecting to servers (regardless what you put in "map share" and "connect as a different user").
When logged on as a local (not domain) user, Windows appears to try your logged on account first.
With the "IPC$" share used for MMC, these logons will generally pass, even though you might have preferred that they failed and gave you a chance to specify different credentials.
Usually if you have a mapped drive connected to some server first, then access to the "IPC$" share (eg. for MMC) will use those same credentials.
Hope that helps.

Actions #3

Updated by Guenther Alka almost 2 years ago

Problem happens as local user root, no AD involved


fffffe118826f648 1 1ee480c599e NAS\root

Actions #4

Updated by Gordon Ross over 1 year ago

Can you get the output of "::smbuser -v" for that user?
In particular, I'd like to see the user flags.

Actions #5

Updated by Guenther Alka over 1 year ago

::smbuser -v

SMB user information (fffffe11a3599b48):
UID: 1
SSNID: 1ee6373549f
State: 1 (LOGGED_ON)
Flags: 0x00000010 <ADMIN>
Credential: fffffe118143de90
Reference Count: 2
User Account: NAS\root

Actions #6

Updated by Gordon Ross 12 months ago

OK, so your user has the ADMIN flag set, which means MMC functions should work.
Can you get a network capture of the failure and attach?

Actions #7

Updated by Guenther Alka 12 months ago

Not sure what has happened in the meantime
I am currently on OmniOS 151044 and Windows 10 Pro 22H2.

When I connect to OmniOS I get a warning that the computer cannot be connected but when I confirm listing of usera, groups, open files seems ok now.I can also modify share acl

When I create a remote group with membersI had to reenter login but not sure if that is normal.

When I try to create a user I get a remote RPC protocol error. Not sure if remote user creation is not possible.


Also available in: Atom PDF