Using "." (period) in user names in SCALE >=22.12.3

[ljr]

Hi everyone,

I have been experimenting with TrueNAS for Homeserver and SoHo-Use and I like it very much.
I have two instances running at home and at my parents' house, one still running TrueNAS-SCALE-22.12.2, the other one running -22.12.3.2.

So far, I have set up all user accounts with usernames in the format "prename.surname" (e.g. "john.doe", just like in our email-addresses), which wasn't any problem at all.
However, yesterday I tried adding a new user on the 22.12.3.2 machine using the same format and it failed with an validation error.
The "."-character is not (or no longer?) included in the valid character list.

On my 22.12.2 machine I can still add usernames with periods without any problems.

So my question is: Are periods allowed in Usernames?

They were apparantly allowed and I already have a couple of users with periods. I am not very keen on mixing username formats since the same format is already used as windows logins and email addresses. So I am kinda hoping, that this is a bug in 22.12.3.x?

The online help is not accurate at this point. Or at least it leaves room for interpretation.
The tooltip in the "add user tab" e.g. shows the following.
My interpretation (of course :)) is, that the period before the dollar sign is not part of the unallowed chars but is just ending the sentence.

Help: Username
Usernames can be up to 32 characters long. Usernames cannot begin with a hyphen (-) or contain a space, tab, or these characters: , : + & # % ^ ( ) ! @ ~ * ? < > =. $ can only be used as the last character of the username.

Thanks, everyone.
Lukas


Error Message:

ValidationErrors

[EINVAL] username: Valid characters for a username are: 'a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, _, -, $'

Error: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/middlewared/main.py", line 204, in call_method result = await self.middleware._call(message['method'], serviceobj, methodobj, params, app=self) File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1344, in _call return await methodobj(*prepared_call.args) File "/usr/lib/python3/dist-packages/middlewared/service.py", line 940, in create rv = await self.middleware._call( File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1344, in _call return await methodobj(*prepared_call.args) File "/usr/lib/python3/dist-packages/middlewared/schema.py", line 1377, in nf args, kwargs = clean_and_validate_args(args, kwargs) File "/usr/lib/python3/dist-packages/middlewared/schema.py", line 1371, in clean_and_validate_args raise verrors middlewared.service_exception.ValidationErrors: [EINVAL] username: Valid characters for a username are: 'a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, _, -, $'

 

[ljr]

In addition to that, I can no longer change passwords of existing usernames with ".".
Same error message.

I am wondering, whether or not "."-usernames were never possible and it was a bug before or if they were possible and it is a bug now....

 

[HoneyBadger]

Hello @ljr

Looks like blocking the . character was an unintended bug introduced to the middleware in 22.12.3 - there is a fix in for 22.12.4 that should address it.

https://ixsystems.atlassian.net/browse/NAS-122821

If the machine running 22.12.3.2 now (your parents?) was running 22.12.2 or earlier previously, you can revert to this environment from System Settings -> Boot and choosing to Activate the earlier version.

 

[ljr]

Hello @HoneyBadger,

thank you very much for your reply and for the link to the bug report (didn't show up in my Google results).

Knowing that it is a already reported bug and that "." is in general allowed in user names is already great news. I'll patiently wait for 22.12.4.

I recently learned about rebooting to previous environments through the UI. I did try booting to 22.12.2 yesterday (I thought I'll just boot to a previous version, add the user with "." and then return to the current version). For some reason, I was not able to add the user in the "reverted" environment neither. Might have been late, though.

Thanks again!

 

[2GOOD]

I've noticed another change to user account names in TrueNAS-SCALE-22.12.3.3

Code:

middlewared.service_exception.ValidationErrors: [EINVAL] username: Username must start with a letter or an underscore

Now I can not change the user's password, tried from ssh but I get:
passwd: Authentication token manipulation error

 

[vitexeon]

I have a lot of user logins that start with NUMBERS, for example 8810-ritter, 7411-office, where numbers have a certain meaning for me in structuring... Why was it forbidden to create a user where is the number at the beginning? what kind of nonsense, in order to get out of this situation, it is now necessary to write: _8810-ritter, _7411-office what kind of stupid innovation is this that a user cannot start with a digit? Or is it a bug of the latest releases...

 

[joeschmuck]

@vitexeon Your first posting on the forums and you are yelling at someone. We do not mind you saying something but injecting aggravation on the group it against our practice here. I will change all the capitalization that may offend some folks. If you really feel like it, you can submit a bug report or a suggestion to change the issue.

 

[vitexeon]

This is not a cry, these are words of pain and indignation ((( (and the use of capital letters in the post does not exceed 20% in terms of the number of characters, which does not contradict the rules of any forum) Do you have an answer or a solution to the essence of the question ? Is it possible to fix my pain somehow ?

 

[joeschmuck]

Fair enough but it did seam like you were just trying to get a rise out of people and while I did not count the number of words that were all caps, it was a lot, could have been 20% or greater or less, but if less, not by much. It is unfortunate that some people will create an account just to blast at someone, anyone, not saying you did that, but it happens and you were a first time poster. My simple task is to try to keep the forum as safe as possible, as a volunteer, I hope you can understand that. As for a solution, as I said before, submit a bug report or a feature request.

Please note that typically the TrueNAS developers are generally not on these forums. They work with the bug reports and feature requests.

If you are a paying user of TrueNAS then you can call their support line and get a quick answer, paying does have it's advantages. I do not pay so I'm at the mercy of whatever gets published on the forums and if I desire something to be changed, you got it, bug report or feature request.

 

[vitexeon]

Can you make a request for a Bug Report on this issue ? (I don't have access to this section because I'm new)

 

[joeschmuck]

Can you make a request for a Bug Report on this issue ? (I don't have access to this section because I'm new)

Believe it or not, I do not have a Jira account. When they went to this new bug reporting method, I just never signed up for it. I personally have not found any bugs that hadn't already been reported. And I can read the bug reports on this site so I can see what folks are reporting.

So you can't create a Jira account? I didn't realize it had a block for new users.

Also, have you tried the current Beta to see if the problem still exists?

 

[HoneyBadger]

Also, have you tried the current Beta to see if the problem still exists?

The original issue of "period not allowed" has been corrected, but the new issue of "name cannot begin with a number" remains.

Linux distros that prohibit fully numeric usernames typically do so for reasons of preventing ambiguity in commands that can accept both usernames and numeric user/group IDs (chown, chgrp, etc) - imagine a situation where you intended to set permissions to an account with UID 568 such as "apps" but instead a user account named "568" with UID "3001" gets them, because POSIX standards indicate that numerics in a username parameter should attempt to resolve as a name first, and only treated as a UID/GID if resolution fails.

 

[Patrick M. Hausen]

Actually it was a systemd bug that lead to that rather strict enforcement we have now. Some part of the software interpreted "123foo" as numerical 123. sscanf("%d" ...), possibly?