Permission denied after running xwmconfig
 

To change window managers from openbox to KDE, as a regular user I ran xwmconfig. The message I get when xwmconfig closes is:

After this, startx just hangs. How can I get X working again?

A very simple thing: have you checked permission of /home/username/.xinitrc-backup? have you?

I have not. :D Though I have a couple of minor install issues, this is my first hitch in regular operation. New Slackware user here, though I'm not new to Linux.

So. I will chmod .xinitrc-backup and .xinitrc to read and write permission for my user and see if that takes care of it.

Thanks for the reply, Karimo.

As root in my user's directory, I just did:
and the permissions do not change. Again: As root, and the permissions didn't change. Of course xwmconfig still gives the same error.

Screenshot:
http://i15.tinypic.com/2epiwxw.jpg

I made the permissions restrictive for safety reasons, but even if they need to be broader the user can do whatever is needed.

What is going on here?

man chmod

Please...

Thanks for the response, uselpa.

Permissions for both .xinitrc and .xinitrc-backup have been changed to 0755 and there is no improvement. The same error messages are given at exit from xwmconfig, and startx times out and doesn't start X.

as root run:
chown username /home/username
chmod 0700 /home/username

Thank you, tramni1980. I need to work on my chmod skills. :D

the files under your home directory must be owned NOT by root, but by your user account, so: chown and chmod when such things will happen again =)

That makes sense, of course, but the two affected files were owned by the user. So I don't see why they were giving permissions problems.

Anyway, thanks for the reply.

Sometimes permissions of directories are changed by scripts you run and do not understand well. Also when you copy files to a directory as root some permissions change. The issue is not quite clear to me too.

Is not sufficient, sometimes, that the file is owned by the user.
For instance: a file owned by the user with permissions 400 can't be written or executed by the user.
Your .xinitrc files must have had permissions like 400 because, although owned by the user, the user itself couldn't write to that file (infact 400 means: r-- --- --- [Only reading permission only for the user]).
A little clearer now?

Besides, to be able to delete a file from a directory, you must have a write permission to that directory. To be able to cd to a directory, or to modify a file in a directory you have to have the executable perission, etc.

Karimo, tramni1980 - a very belated thank you for your replies. I hadn't noticed them when they were posted.

Everything is running smoothly for months now and I'm chown-ing and chmod-ing as needed.