[SOLVED] Linux PAM User Password Change 500 Error

[utkonos]

In PVE, if a new user account is created using:

Datacenter > Permissions > Users > Add:
User name: test
Realm: Linux PAM standard authentication
> Save

Trying to change the password for the newly created user this way:

Datacenter > Permissions > Users > test > Password:
Password: {password}
Confirm password: {password}
> OK

Results in an error: change password failed: user 'test' does not exist (500)



My guess is that this is by design and not a bug. In this case, should the "Password" button just show a window with a message about this not being the way to change the password. Or even when a {username}@pam account is selected, the "Password" button should be greyed out and not clickable (in the way that the Remove button is when root is selected)?

Alternatively, is this a bug?

 

[dietmar]

You can change the password if the user exists on the system.

 

[utkonos]

@dietmar Could the pathway that I described in the GUI be improved so that there isn't an error that leads the user to think there is a bug?

 

[dietmar]

@dietmar Could the pathway that I described in the GUI be improved so that there isn't an error that leads the user to think there is a bug?

IMHO, the message is quite informative an points exactly to the problem.

 

[utkonos]

I disagree. The first action taken is to create that particular user account. Then the message says that the user account does not exist.

 

[utkonos]

I totally understand that everything I've done and the message that is displayed is all by design. My thoughts are "this is astonishing" because I thought that I just created an account (which I clearly did not). This is one of those areas of interface design that appears to me to break the Principle of least astonishment:
https://en.wikipedia.org/wiki/Principle_of_least_astonishment

But, as always with design features that appear to one person to break POLA, to the original designers, it is not astonishing and is totally logical and working as designed.

No worries. I'll close this thread as solved.

 

[IStoleYourCoconut]

In PVE, if a new user account is created using:

Datacenter > Permissions > Users > Add:
User name: test
Realm: Linux PAM standard authentication
> Save

Trying to change the password for the newly created user this way:

Datacenter > Permissions > Users > test > Password:
Password: {password}
Confirm password: {password}
> OK

Results in an error: change password failed: user 'test' does not exist (500)

View attachment 44768

My guess is that this is by design and not a bug. In this case, should the "Password" button just show a window with a message about this not being the way to change the password. Or even when a {username}@pam account is selected, the "Password" button should be greyed out and not clickable (in the way that the Remove button is when root is selected)?

Alternatively, is this a bug?

Wow. What a reply.

Technically correct if you know that creating a user in the GUI doesn't add it under linux. But not helpful when you rightfully expect to add it for you. Otherwise, creating a user should at least throw a warning with "remember to add the user per cli if you added the user under PAM".

I mean why even give the option to create a user with PAM under the GUI if it doesn't add the user in the first place. This is not thought through.

 

[piook]

Wow. What a reply.

Technically correct if you know that creating a user in the GUI doesn't add it under linux. But not helpful when you rightfully expect to add it for you. Otherwise, creating a user should at least throw a warning with "remember to add the user per cli if you added the user under PAM".

I mean why even give the option to create a user with PAM under the GUI if it doesn't add the user in the first place. This is not thought through.

Agreed, this is quite frankly, insulting that a "staff member" would not properly explain what is needed here. What is the point of the forums if they do not answer questions that people are going to come across. Also, bad UI design just like @IStoleYourCoconut stated, "why even give the option..."