I am unable to launch MCC as "user" Clicking on MCC icon and mgaaplet
nothing happens

running drakcong from CL

[faeychild@unimatrix ~]$ drakconf
Too late to run INIT block at
/usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
The value for the SHELL variable was not found the /etc/shells file

This incident has been reported.

The content of /etc/shells is

/bin/bash
/bin/sh
/usr/bin/bash
/usr/bin/dash
/usr/bin/sh

It will launch fine from root and from "junk"

Do I have a permissions problem?

regards

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On 22/5/21 3:07 pm, faeychild wrote:
>
>
> I am unable to launch MCC as "user" Clicking on MCC icon and mgaaplet
> nothing happens
>

No I have a an environment problem

~]$ set | grep -i SHELL
SECSHELL=1
SHELL=/bin/bin
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor

env | grep -i SHELL
SHELL=/bin/bin
SHELL_SESSION_ID=95fdac2d32b646b194b699e29c78edd7
SECSHELL=1

printenv | grep -i SHELL
SHELL=/bin/bin
SHELL_SESSION_ID=95fdac2d32b646b194b699e29c78edd7
SECSHELL=1

I tried defining in /etc/environment
and tried to declare in the bash CL but it isn't permanent.
Finally put it in ~/.bashrc where it works.

I would be curious to know where $SHELL is initially defined and how it
is corrupted

Regards.

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On 22/5/21 4:22 pm, faeychild wrote:

>
> I would be curious to know where $SHELL is initially defined and how it
> is corrupted

It's disquietingly defined everywhere

[root@unimatrix ~]# grep -r "SHELL=" /etc/*
/etc/anacrontab:SHELL=/bin/sh
/etc/crontab:SHELL=/bin/bash
/etc/default/useradd:SHELL=/bin/bash
/etc/environment:SHELL=/bin/bash
grep: /etc/grub2-efi.cfg: No such file or directory
/etc/profile.d/10tmpdir.sh: export SECSHELL=1
/etc/profile.d/01msec.sh: export SECSHELL=1
/etc/shorewall/shorewall.conf:SHOREWALL_SHELL=/bin/sh
/etc/shorewall6/shorewall6.conf:SHOREWALL_SHELL=/bin/sh

SO... which was original and was changed to reflect `SHELL=/bin/bin` and
then broke "drakconfig" and trashed my quiet afternoon.

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On Sat, 22 May 2021 16:22:12 +1000, faeychild wrote:

> I tried defining in /etc/environment
> and tried to declare in the bash CL but it isn't permanent.
> Finally put it in ~/.bashrc where it works.
>
> I would be curious to know where $SHELL is initially defined

A place to start looking
grep -ir shell /etc/profile.d/*.sh

Hnnnm, me too. man bash under INVOCATION does not say.

Looking through my brain book I see
$ uh login path order
_path_login_order_ Typical Non-gui login order of execution is
_path_login_order_ /etc/login.defs
_path_login_order_ /etc/profile which sources /etc/profile.d/*.sh scripts
_path_login_order_ ~/.bash_profile which sources ~/.bashrc
_path_login_order_ ~/.bashrc sources /etc/bashrc
_path_login_order_ /usr/share/config/kdm/kdmrc

$ uh dm login
_login_dm_de_system_loc_ /var/cache/lightdm/dmrc/(user).dmrc
_login_dm_de_system_loc_ /var/lib/AccountsService/users/(user)
_login_dm_de_system_loc_ /var/lib/lightdm-data/(user)
_login_dm_de_system_loc_ $HOME/.dmrc
_login_tool_ dm-tool switch-to-user browser
_login_tool_ dm-tool switch-to-user $_sys_owner
_Change_graphic_on_login_screen_ /etc/X11/gdm/Init/Default
_path_login_order_ /usr/share/config/kdm/kdmrc

> and how it is corrupted

That would require a bit of work on your part. I had to modify the
INVOCATION files to dump desired info for debugging these kinds of
problems.

Have you tried a test account, say junk, to see if it is a system
wide problem or user problem?

On 5/22/21 6:49 AM, Bit Twister wrote:
> Have you tried a test account, say junk, to see if it is a system
> wide problem or user problem?

He mentioned "junk" works OK in the original post.

TJ

On Sat, 22 May 2021 07:44:31 -0400, TJ wrote:
> On 5/22/21 6:49 AM, Bit Twister wrote:
>> Have you tried a test account, say junk, to see if it is a system
>> wide problem or user problem?
>
> He mentioned "junk" works OK in the original post.

Shuckey dern, you are correct. Back to speed reading 101 for me.

As for an owner check the command would be
find $HOME \( -not -user $USER -or -not -group $USER \) -exec ls -ald '{}' \;

I have not done Plasma in years, so not sure of what is executed.
Usual problems occur if save session is enabled.

Other places to dink up thing is scripts running from the autostart
directory.

Usual kde/Plasma check is to just rename the kde sub-directory log
out/in. Of course that still could save the current environment
back into the kde directory.

I found it preferable to do that work via root with the user
not logged in.

On 22/5/21 8:49 pm, Bit Twister wrote:
> On Sat, 22 May 2021 16:22:12 +1000, faeychild wrote:
>
>> I tried defining in /etc/environment
>> and tried to declare in the bash CL but it isn't permanent.
>> Finally put it in ~/.bashrc where it works.
>>
>> I would be curious to know where $SHELL is initially defined
>
> A place to start looking
> grep -ir shell /etc/profile.d/*.sh

grep -ir shell /etc/profile.d/*.sh
/etc/profile.d/01msec.sh:# shell security options
/etc/profile.d/01msec.sh:if [ -z "$SECSHELL" -a -r /etc/security/shell
]; then
/etc/profile.d/01msec.sh: . /etc/security/shell
/etc/profile.d/01msec.sh: export SECSHELL=1
/etc/profile.d/10tmpdir.sh:if [ -z "$SECSHELL" -a -r /etc/security/shell
]; then
/etc/profile.d/10tmpdir.sh: . /etc/security/shell
/etc/profile.d/10tmpdir.sh: export SECSHELL=1
/etc/profile.d/20mc.sh:# Don't define aliases in plain Bourne shell
/etc/profile.d/40configure_keyboard.sh:# shell
/etc/profile.d/40configure_keyboard.sh:# For other shells, I assume $-
is not available
/etc/profile.d/40configure_keyboard.sh:if [ "$SHELL" = "/bin/bash" ]; then
/etc/profile.d/60alias.sh:# Don't define aliases in plain Bourne shell
/etc/profile.d/95bash-extras.sh: # allow mixing history when several
shells running in parallel
/etc/profile.d/ladspa.sh:# Set LADSPA_PATH for Bash shell
/etc/profile.d/vte.sh:# Not an interactive shell?

>
> That would require a bit of work on your part. I had to modify the
> INVOCATION files to dump desired info for debugging these kinds of
> problems.
>
> Have you tried a test account, say junk, to see if it is a system
> wide problem or user problem?
>

Root and junk were fine. Only user was affected.

I have done only one "experiment" that could have some bearing. I did
edit my line in /etc/passwd to be /bin/nologin. Just to see what would
happen.

Surprise surprise! I couldn't log in.

But that is not going to corrupt the bash env variable.

But I''l try it again later this afternoon

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On 22/5/21 10:21 pm, Bit Twister wrote:
> On Sat, 22 May 2021 07:44:31 -0400, TJ wrote:
>> On 5/22/21 6:49 AM, Bit Twister wrote:
>>> Have you tried a test account, say junk, to see if it is a system
>>> wide problem or user problem?
>>
>> He mentioned "junk" works OK in the original post.
>
> Shuckey dern, you are correct. Back to speed reading 101 for me.
>
> As for an owner check the command would be
> find $HOME \( -not -user $USER -or -not -group $USER \) -exec ls -ald '{}' \;

The prompt returns - nothing found

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On 23/5/21 8:32 am, faeychild wrote:

> But that is not going to corrupt the bash env variable.
>
> But I''l try it again later this afternoon

Also later I will remove my override entry in .bashrc and see if the
SHELL env returns to /bib/bin.

I should have done that yesterday. clearly not thinking well.

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On Sat, 22 May 2021 03:11:37 -0400, faeychild <faeychild@nomail.afraid.org> wrote:
> SO... which was original and was changed to reflect `SHELL=/bin/bin` and
> then broke "drakconfig" and trashed my quiet afternoon.

What does "grep $USER /etc/passwd" show? The 7th (last) variable defines the
shell to use, and does set the initial value used for $SHELL in the environment
when the user logs in, though it may be altered by scripts later in the login
procedure.

See "man login".

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

On Sun, 23 May 2021 08:34:53 +1000, faeychild wrote:
> On 22/5/21 10:21 pm, Bit Twister wrote:
>> On Sat, 22 May 2021 07:44:31 -0400, TJ wrote:
>>> On 5/22/21 6:49 AM, Bit Twister wrote:
>>>> Have you tried a test account, say junk, to see if it is a system
>>>> wide problem or user problem?
>>>
>>> He mentioned "junk" works OK in the original post.
>>
>> Shuckey dern, you are correct. Back to speed reading 101 for me.
>>
>> As for an owner check the command would be
>> find $HOME \( -not -user $USER -or -not -group $USER \) -exec ls -ald '{}' \;
>
>
> The prompt returns - nothing found

Which is a valid/normal result.

The fact that junk works indicates the problem is in your account
and no further research is required for system login files.

On 23/5/21 9:22 am, David W. Hodgins wrote:
> On Sat, 22 May 2021 03:11:37 -0400, faeychild
> <faeychild@nomail.afraid.org> wrote:
>> SO... which was original and was changed to reflect `SHELL=/bin/bin` and
>> then broke "drakconfig" and trashed my quiet afternoon.
>
> What does "grep $USER /etc/passwd" show? The 7th (last) variable defines
> the
> shell to use, and does set the initial value used for $SHELL in the
> environment
> when the user logs in, though it may be altered by scripts later in the
> login

That's the best clue so far for the origin
But my passwd login shell was is /bin/bash. Surely no program would
change that - I hope

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On Sun, 23 May 2021 12:18:32 +1000, faeychild wrote:
> On 23/5/21 9:22 am, David W. Hodgins wrote:
>> On Sat, 22 May 2021 03:11:37 -0400, faeychild
>> <faeychild@nomail.afraid.org> wrote:
>>> SO... which was original and was changed to reflect `SHELL=/bin/bin` and
>>> then broke "drakconfig" and trashed my quiet afternoon.
>>
>> What does "grep $USER /etc/passwd" show? The 7th (last) variable defines
>> the
>> shell to use, and does set the initial value used for $SHELL in the
>> environment
>> when the user logs in, though it may be altered by scripts later in the
>> login
>
> That's the best clue so far for the origin
> But my passwd login shell was is /bin/bash. Surely no program would
> change that - I hope

Problem has got to be in your account.

Back out your .bashrc change, boot run level 3, log in and
echo $SHELL

if valid you know something in Desktop Environment is causing the
problem.

On 23/5/21 12:24 pm, Bit Twister wrote:

> Problem has got to be in your account.

Yes! and it has cleared up
>
> Back out your .bashrc change, boot run level 3, log in and
> echo $SHELL

it was /bin/bash

and it still is, on the Desktop with the .bashrc shell entry remmed out

FWIW Since the shell mod and the user passwd editing yesterday I
have a new user on the login screen called "system user for..."

It's not in the passwd file

>
> if valid you know something in Desktop Environment is causing the
> problem.
>

I have been going over the events of yesterday as much as I remember and
I am staring to blame myself.
When I edited the passwd file experimentally to show /bin/nologin, did I
restore it properly afterward?.
Could I have typed /bin/bin?
Have I given myself the runaround?

It seem more likely than an OS fault. PEBKAC

I suppose the upside of dumb-ass errors is the education you get from them.

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On Sun, 23 May 2021 13:23:15 +1000, faeychild wrote:
> On 23/5/21 12:24 pm, Bit Twister wrote:
>
>> Problem has got to be in your account.
>
> Yes! and it has cleared up
>>
>> Back out your .bashrc change, boot run level 3, log in and
>> echo $SHELL
>
> it was /bin/bash
>
> and it still is, on the Desktop with the .bashrc shell entry remmed out
>
> FWIW Since the shell mod and the user passwd editing yesterday I
> have a new user on the login screen called "system user for..."
>
> It's not in the passwd file

Yep, the Greeter keeps a list of users so it knows which Display Environment
is to be used for the user.

And, is yet another reason not to edit /etc/passwd file with an editor.

>> if valid you know something in Desktop Environment is causing the
>> problem.
>>
>
> I have been going over the events of yesterday as much as I remember and
> I am staring to blame myself.

You might want to run
pwck -r
grpck -r
and if nothing comes back, you know passwd and group are in sync.

> When I edited the passwd file experimentally to show /bin/nologin, did I
> restore it properly afterward?.
> Could I have typed /bin/bin?
> Have I given myself the runaround?
>
> It seem more likely than an OS fault. PEBKAC
>
> I suppose the upside of dumb-ass errors is the education you get from them.

On 23/5/21 6:17 pm, Bit Twister wrote:

>
> You might want to run
> pwck -r
> grpck -r
> and if nothing comes back, you know passwd and group are in sync.
>

As root

~]# pwck -r
user 'adm': directory '/var/adm' does not exist
user 'news': directory '/var/spool/news' does not exist
user 'uucp': directory '/var/spool/uucp' does not exist
user 'nscd': program 's/bin/nologin' does not exist
user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
pwck: no changes

[root@unimatrix ~]# grpck -r
'faeychild' is a member of the 'lp' group in /etc/group but not in
/etc/gshadow
'faeychild' is a member of the 'cdrom' group in /etc/group but not in
/etc/gshadow
'faeychild' is a member of the 'cdwriter' group in /etc/group but not in
/etc/gshadow
'faeychild' is a member of the 'systemd-journal' group in /etc/group but
not in /etc/gshadow
'faeychild' is a member of the 'scanner' group in /etc/group but not in
/etc/gshadow
[root@unimatrix ~]#

Does faeychild need to be in gshadow?

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On Sun, 23 May 2021 18:22:53 -0400, faeychild <faeychild@nomail.afraid.org> wrote:
> [root@unimatrix ~]# grpck -r
> 'faeychild' is a member of the 'lp' group in /etc/group but not in
> /etc/gshadow
> 'faeychild' is a member of the 'cdrom' group in /etc/group but not in
> /etc/gshadow
> 'faeychild' is a member of the 'cdwriter' group in /etc/group but not in
> /etc/gshadow
> 'faeychild' is a member of the 'systemd-journal' group in /etc/group but
> not in /etc/gshadow
> 'faeychild' is a member of the 'scanner' group in /etc/group but not in
> /etc/gshadow
> [root@unimatrix ~]#
>
> Does faeychild need to be in gshadow?

Did you copy one or more of the files /etc/passwd, /etc/shadow, /etc/group,
and /etc/gshadow from another install or manually edit them?

The files are supposed to be kept in sync with each other and the standard
utilities for working with them ensure that's done.

I think it's saying that according to /etc/group your id is in the lp group,
but isn't in the lp group according to /etc/gshadow. Same with the other
groups it's showing.

I have no idea what type of impact that may have.

First check the permissions ...
# ll /etc/passwd /etc/shadow /etc/group /etc/gshadow
-rw-r--r-- 1 root root 2581 Jan 1 17:48 /etc/group
-r--r----- 1 root shadow 2188 Jan 1 17:48 /etc/gshadow
-rw-r--r-- 1 root root 5652 Feb 7 17:04 /etc/passwd
-r--r----- 1 root shadow 2444 Feb 7 17:04 /etc/shadow

Read "man pwconv". After fixing the permissions and ownership if needed, I think
running the "grpconv" command will repair the gshadow file.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

On 2021-05-23, faeychild <faeychild@nomail.afraid.org> wrote:
> On 23/5/21 6:17 pm, Bit Twister wrote:
>
>>
>> You might want to run
>> pwck -r
>> grpck -r
>> and if nothing comes back, you know passwd and group are in sync.
>>
>
> As root
>
> ~]# pwck -r
> user 'adm': directory '/var/adm' does not exist
> user 'news': directory '/var/spool/news' does not exist
> user 'uucp': directory '/var/spool/uucp' does not exist
> user 'nscd': program 's/bin/nologin' does not exist

This one seems to have been a typo you probably introduced in your
playing around with nologin.
It should be /sbin/nologin, not s/bin/nologin

> user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
> pwck: no changes

The rest do nor really matter unless you want something to actually
login to those users.
(They also exist on my Mga8-- some problem in the installation rpm
scripts I presume).

>
>
>
> [root@unimatrix ~]# grpck -r
> 'faeychild' is a member of the 'lp' group in /etc/group but not in
> /etc/gshadow
> 'faeychild' is a member of the 'cdrom' group in /etc/group but not in
> /etc/gshadow
> 'faeychild' is a member of the 'cdwriter' group in /etc/group but not in
> /etc/gshadow
> 'faeychild' is a member of the 'systemd-journal' group in /etc/group but
> not in /etc/gshadow
> 'faeychild' is a member of the 'scanner' group in /etc/group but not in
> /etc/gshadow

Since you undoubtedly do not have any passwords anyway, it does not
matter. However, if you did have group passwords, this would allow you
to user your group identity without a password (man gshadow)

> [root@unimatrix ~]#
>
> Does faeychild need to be in gshadow?
>
>
>

On 24/5/21 9:14 am, David W. Hodgins wrote:

> Did you copy one or more of the files /etc/passwd, /etc/shadow, /etc/group,
> and /etc/gshadow from another install or manually edit them?

I don't remember but I doubt that I would transfer that type of file.

>
> The files are supposed to be kept in sync with each other and the standard
> utilities for working with them ensure that's done.
>
> I think it's saying that according to /etc/group your id is in the lp
> group,
> but isn't in the lp group according to /etc/gshadow. Same with the other
> groups it's showing.
>
> I have no idea what type of impact that may have.
>
> First check the permissions ...
> # ll /etc/passwd /etc/shadow /etc/group /etc/gshadow
> -rw-r--r-- 1 root root   2581 Jan  1 17:48 /etc/group
> -r--r----- 1 root shadow 2188 Jan  1 17:48 /etc/gshadow
> -rw-r--r-- 1 root root   5652 Feb  7 17:04 /etc/passwd
> -r--r----- 1 root shadow 2444 Feb  7 17:04 /etc/shadow
>
> Read "man pwconv". After fixing the permissions and ownership if needed,
> I think
> running the "grpconv" command will repair the gshadow file.
>
> Regards, Dave Hodgins
>

Ok I've snipped this text. Believe it or not I was completely unaware
of the group shadow file.

regards
--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On 24/5/21 9:36 am, William Unruh wrote:
> On 2021-05-23, faeychild <faeychild@nomail.afraid.org> wrote:
>> On 23/5/21 6:17 pm, Bit Twister wrote:
>>
>>>
>>> You might want to run
>>> pwck -r
>>> grpck -r
>>> and if nothing comes back, you know passwd and group are in sync.
>>>
>>
>> As root
>>
>> ~]# pwck -r
>> user 'adm': directory '/var/adm' does not exist
>> user 'news': directory '/var/spool/news' does not exist
>> user 'uucp': directory '/var/spool/uucp' does not exist
>> user 'nscd': program 's/bin/nologin' does not exist
>
> This one seems to have been a typo you probably introduced in your
> playing around with nologin.
> It should be /sbin/nologin, not s/bin/nologin

Agreed. Some massive scrambling seems to have occurred.
mea culpa

>
>> user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
>> pwck: no changes
>
> The rest do nor really matter unless you want something to actually
> login to those users.
> (They also exist on my Mga8-- some problem in the installation rpm
> scripts I presume).

I sort of presumed that the entries may be created when the program runs

>
> Since you undoubtedly do not have any passwords anyway, it does not
> matter. However, if you did have group passwords, this would allow you
> to user your group identity without a password (man gshadow)

So much to read - so little time

regards

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On 24/5/21 9:14 am, David W. Hodgins wrote:

>
> Read "man pwconv". After fixing the permissions and ownership if needed,
> I think
> running the "grpconv" command will repair the gshadow file.
>
> Regards, Dave Hodgins
>

"grpconv" ran clean

and now "grpck -r" returns nothing

regards
--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On Mon, 24 May 2021 08:22:53 +1000, faeychild wrote:
> On 23/5/21 6:17 pm, Bit Twister wrote:
>
>>
>> You might want to run
>> pwck -r
>> grpck -r
>> and if nothing comes back, you know passwd and group are in sync.
>>
>
> As root
>
> ~]# pwck -r
> user 'adm': directory '/var/adm' does not exist
> user 'news': directory '/var/spool/news' does not exist
> user 'uucp': directory '/var/spool/uucp' does not exist
> user 'nscd': program 's/bin/nologin' does not exist
> user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
> pwck: no changes

As root, run mkdir on each directory that does not exist.

No good idea why nscd is dinked up uless a problem in the biological
unit between keyboard and chair.

s/bin/nologin should be /sbin/nologin

>
>
>
> [root@unimatrix ~]# grpck -r
> 'faeychild' is a member of the 'lp' group in /etc/group but not in
> /etc/gshadow
> 'faeychild' is a member of the 'cdrom' group in /etc/group but not in
> /etc/gshadow
> 'faeychild' is a member of the 'cdwriter' group in /etc/group but not in
> /etc/gshadow
> 'faeychild' is a member of the 'systemd-journal' group in /etc/group but
> not in /etc/gshadow
> 'faeychild' is a member of the 'scanner' group in /etc/group but not in
> /etc/gshadow
> [root@unimatrix ~]#

Any shadow or gshadow messages indicate someone or something
is modifying /etc/password or /etc/group without using the
correct maintenance tool.

> Does faeychild need to be in gshadow?

Well as far as I am concerned, any message from pwck or grpck
is a problem. I run both in my nightly sys_audit cron job.

I suggest you should/need to run
usermod --append --groups \
lp cdrom cdwriter usb systemd-journal wireshark scanner

after all changes run
pwck -r
grpck -r
again.

On Mon, 24 May 2021 11:38:10 +1000, faeychild wrote:
> On 24/5/21 9:14 am, David W. Hodgins wrote:
>
>>
>> Read "man pwconv". After fixing the permissions and ownership if needed,
>> I think
>> running the "grpconv" command will repair the gshadow file.
>>
>> Regards, Dave Hodgins
>>
>
> "grpconv" ran clean
>
> and now "grpck -r" returns nothing
>
> regards

Looking in my faeychild file you might want to verify the groups
you want to be in. My file has you with
lp cdrom cdwriter usb systemd-journal wireshark scanner

Check with id -nG

On Mon, 24 May 2021 08:22:53 +1000, faeychild wrote:
> On 23/5/21 6:17 pm, Bit Twister wrote:
>
>>
>> You might want to run
>> pwck -r
>> grpck -r
>> and if nothing comes back, you know passwd and group are in sync.
>>
>
> As root
>
> ~]# pwck -r
> user 'adm': directory '/var/adm' does not exist
> user 'news': directory '/var/spool/news' does not exist
> user 'uucp': directory '/var/spool/uucp' does not exist
> user 'nscd': program 's/bin/nologin' does not exist
> user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
> pwck: no changes

Forgot to add after running mkdir, you need to run chmod
to set uid/gid to same as user's uid/gid

On 24/5/21 12:10 pm, Bit Twister wrote:

>
> Looking in my faeychild file you might want to verify the groups
> you want to be in. My file has you with
> lp cdrom cdwriter usb systemd-journal wireshark scanner
>
> Check with id -nG
>
>

id -nG
faeychild lp cdrom cdwriter systemd-journal scanner
[faeychild@unimatrix ~]$

Clearly some minor slippage.
I'm a tad impressed with you "Dossier"

It may put the CIA to shame

[root@unimatrix ~]# usermod -a -G wireshark, usb, faeychild
usermod: group 'wireshark' does not exist
usermod: group '' does not exist

where does group '' come from?

--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso