-------- Forwarded Message --------
Subject: Re: User Can Not Log In
Date: Fri, 24 Feb 2017 17:42:30 -0600
From: Michael Milliman <michael.e.milli...@gmail.com>
To: Dan Norton <dnor...@mindspring.com>
On 02/24/2017 02:12 PM, Dan Norton wrote:
-----Original Message-----
From: Michael Milliman <michael.e.milli...@gmail.com>
Sent: Feb 23, 2017 8:40 PM
To: debian-user@lists.debian.org
Subject: Re: User Can Not Log In
On 02/23/2017 04:16 PM, GiaThnYgeia wrote:
Michael Milliman:
On 02/23/2017 10:47 AM, Dan Norton wrote:
While playing around with Xfce, startx, and fvwm I've managed to
clobber something such that the user can't log in. All attempts result
in a fresh login box with my inputs removed. However, it is still
possible to log in as root.
fvwm was installed using Synaptic and run from an Xfce terminal
session. When it did not produce the expected result, I shut down and
rebooted. At this point it was no longer possible to log in as user -
only as root.
Do I have to rename /home/<user>, delete <user>, then re-define it as
a new user and restore its home directory?
Or is there a better way?
It should be possible to do some serious research and figure out exactly
which package is croaking, and why, and then edit the configuration file
for that package in /home/<user>. But in my experience with similar
situations, this takes much more time than it is worth. I have found
that usually just deleting the configuration files in /home/<user> will
work. This is probably easier than the solution that you propose, but
your solution should work as well, as long as you don't copy back the
configuration files when you do the restore.
Encouraged by the previous brave response, I have done similar hacks in
the past.
1 One thing I look at is date ordered of @home/ directory. See what
was last edited and reconfigured, most probably is the culprit. With
some packages renaming that directory in the home folder as something
else temporary (ie home/gnubg --> home/gnubg.tmp may result into a
login and when you run gnubg it will act as started for first time --
not a good example I am afraid). 1.1 It may be more than one thing
gone bad.
2 Create a new user, copy config files that you don't suspect are
related to the problem and then go one at a time with the rest.
3 See if the file and directory rights are still in tact in your #home,
maybe you locked yourself out. Root should always have the right to set
a new password for a user.
4 Are you switching between desktops, do you have an alternative
(openbox .. gnome .. mate ..etc). Did you try a different desktop? It
may relate to desktop settings or if you removed one you may have
affected an other in case you were crossing desktop specific packages.
5 Check your autostart folders for crap you can remove.
All very good suggestions...but I usually just get fed up looking before
I find the problem, and just go for broke. It seems much easier to just
re-apply my preferences than to continue digging. But it is a little
like using a shot-gun rather than a scalpel.
The user has been deleted and re-defined with a different password. It is now
possible to log in as that user. I am now cautiously restoring the user's home
directory, trying to avoid pulling in some configuration which might cause
trouble again.
It seems that ~/.config would be a source of configurations, but is that the
only one?
~/.config is the most likely, however, your desktop also usually has
configuration files in folders like ~/.gnome or ~/.mate (or maybe its
~/.mate-desktop), etc. If the problem exists under multiple desktop
environments, then something in ~/.config is almost certainly the
problem. One other thing, though. You say that you can log in as
root....question: does the root login take you to a graphical desktop??
This is disabled in most installations, though it can be enabled (I have
modified my configuration to allow graphical login for root). If you
log in as root from the command line, you might try logging in as the
user from the command line to make sure that works. If you can log in
as root from the graphical environment, then the problem is certainly in
the user configurations probably in ~/.config. If your system is not
set up to allow root logins from the graphical environment, then this
can't be confirmed, but ~/.config is the most likely culprit. If your
system will allow graphical root logins, and the same problem happens
with graphical root login, then the problem is over in /etc, a much more
troubling problem.
Were it my system, I would simply delete all hidden files in
/home/<user> with the command rm -r /home/<user>/.*, however, a very
reasonable first gambit would be to rm -r /home/<user>/.config, and then
the more comprehensive rm -r /home/<user>/.*. In either case, you lose
not actual data, just configuration/setup/preference information that
has to be re-done.
As I wrote this, I thought about another quick test to run. Create a
new user (from the command line is fine), and then log in with that new
user from the graphical login. If that is successful, then again, the
problem is certainly in the original user's home folder configuration
files. That new user can then be removed. You could also copy over all
the configuration files thus created to the old user's folder with
something like cp -r /home/<new user>/.* /home/<user> You would then
have to make sure and change the ownership of the copied configuration
files (chown -R <user>:<user> /home/<user>). This would cause a minimum
of disruption of configuration, and may well solve the problem.
Sorry for so long a response, but I wanted to present all of the various
options that may solve the problem so you can choose what you think
would work best in your situation.
- Dan
--
73's de Mike, WB5VQX
