When I login, I receive and error that the permissions are wrong for the file .dmrc

Changing your home to 751 stops this. BUT delivering this error with hardy would be bad.

In what way does this relate to the Unicode migration tool you chose as a package hint to report this bug?

I have already fixed my home directory permissions, and that did take care of it. It would scare many users though.

As for the comment about the Unicode migration tool, I assume that comment is for Tobias, since I do not even know what it is.

Thanks, everyone!

Tom, that comment is for you. You filed a bug against this package, not Tobias.

Nope, I assigned it to the package.
I searched for dmrc and only this package showed up
https://launchpad.net/ubuntu/+search?text=dmrc

Because german Google only showed Pages about the error, but not about the package. Seems the first guess isn't always the right one.

With a little help I now figured out the file belongs to GDM.

I also had the same problem the other day, this is with 8.04 final. I fixed it by changing the permissions for my home folder to read/write by me and my group (only me in it) and no access for all others. No problems so far.

Confirming as asharin has also experienced the problem.

The error message should, from reading the source of gdm 2.20.6-0ubuntu1, say

"User's $HOME/.dmrc file is being ignored. This prevents the default session and language from being saved. File should be owned by user and have 644 permissions. User's $HOME directory must be owned by user and not writable by other users."

That seems to match what the code checks and be clear. It's warning that the .dmrc file could be modified by someone other than the user. To avoid this, do "cd && chmod go-w . .dmrc" to remove `write' permission for `group' and `other'.

I know the solution (I fixed it immediately on my box), I was just mentioning it as a bug because it would scare the bejeesus out of a new user. If it is no longer a bug in the install, it is no longer a problem (although, from what I read above, it may still exist in Ubuntu Hardy release) and can be marked fixed.

How would you go about turning this annoying message off? I'm hosting a server (the PC is a dedicated server) so locking my home directory (containing files shared by FTP) would be a BAD IDEA. However, I VNC to this machine remotely, and this error is popping up and preventing the system from completely loading (thus it doesn't load VNC server until someone clicks OK, but I'm not going to be here to click OK, thus rendering it USELESS). I WANT others to access my home directory, I just want this dumb message to be gone. What can I do to fix it?

Hi CalcProgrammer1, you're being a bit unclear. "I WANT others to access my home directory" -- is that for reading the files in it or creating and deleting files too? If the latter, then I don't know of a workaround since my suggestion above, cd && chmod go-w . .dmrc, removes write access for others to your home directory. Could you instead have a subdirectory of $HOME, give that permissions 777, and use that as the directory that all and sundry can fiddle with?

By "Access" I of course mean all permissions (read/write/delete/create directory/remove directory/etc). All users are in the end just me, but I'm not sure if proftpd (gproftpd) uses a second user account or not. I'm sharing my /home/<username> directory on MY FTP account and /home/<username>/ftp on OTHER FTP accounts (for friends and others). Why would an operating system that is supposed to be infinitely configurable have such a hard block on permissions? If someone needs to give others write access to their home directory, they should not be hindered by annoying messages. I for one consider this in itself to be a bug. If not that, is there a way I could log on automatically as like a root user or something (thus having total access)?

does anybody still get the issue in intrepid? could you describe how to trigger the bug?

I would give this bug the boot. I don't think anyone is experiencing it anymore.

I do have one question though - just because a bug is fixed in Intrepid, that shouldn't affect the status of a bug reported for Hardy - especially since it is an LTS. I had reported a previous bug - reboot does not work in Hardy. This no longer happens in Intrepid (it must have been a kernel bug), but that doesn't fix it in Hardy? Or does the bug get marked fixed anyway? Just wondering.

Anyhoo, I think this bug can be closed, since it no longer happens in Hardy.

I have this bug in intrepid...What do you want to know...I have a fairly fresh install but I have added many packages. It may be caused by trying to use the sessions gui to create startup programs. I'm not linux expert but I can do what you tell me in console.

I have had this bug in Intrepid as well (twice, actually -- I fixed it once several months ago by resetting the permissions for my /home and it's recently come back). I'm really not sure what triggered it, especially this second time, as I haven't added/removed any startup programs recently as far as I remember. Let me know what information I can contribute!

I am experiencing this bug on Intrepid. This install is only 2 days old, and AFAIK I have _never_ run chmod or chown or any other permission changing command. I have installed a fair number of packages through aptitude, including a few from unofficial repositories (Skype, Wine, KDE 4.2 from the Kubuntu PPA). I've also never experienced this problem with the same computer under Hardy (this is a fresh install though, not an upgrade).

I did a normal ubuntu install but then edited my .xsession to setup the xmonad window manager (www.xmonad.org) to replace metacity, but that's the only thing that seems odd about my setup. I still have it load gnome-power-manager and nm-applet and such... although the logout button doesn't work, and since this has to do with session saving maybe that's somehow part of the problem?

The only other hint I can think of is that I first experienced this problem after a failed resume from suspend. If any other information / console output is needed just let me know.

As a workaround, I ran this in the terminal:

sudo chmod -R 700 /home/prophet
sudo chown -R prophet /home/prophet

And that fixed the problem for me. Substitute prophet for your own username. Interestingly, my whole home directory was marked drwxrwxrwx before this, and after it's now drwx------ as expected. But like I said, I never ran any command to change the permissions that way.

> sudo chmod -R 700 /home/prophet

Hasn't that just made every file under there writable and executable?

Yes but only for the user itself. The permissions for the rest of the world are no read,no write, no execute!
Someone can only change the permissions for home and .dmrc file alone.
sudo chmod 700 /home/username
sudo chmod username /home/username/.dmrc
that fixed the problem for me!
thank you garvin.

Could somebody describe how to trigger the issue on a new installation?

I do not know what I did, but it seems like bad juju ...

I did 4 ubuntu fresh installs the last week (just playing around with different desktop managers).

Right now this moment I am coming over this bug on a fresh install of LinuxMint7 = Ubuntu Jaunty.

I am having it on a USB-disk install of Jaunty.

I had it on Xubuntu Jaunty before I did the Mint fresh install today (that was one of the reasons for my fresh install).

I fixed the permissions as the error message suggested. Some xorg restarts later it complains again???

The post before was a bit unclear , sorry:
1. Linux Mint 7 fresh on sda5
2. Ubuntu Jaunty (Gnome) on sdb1 (USB)
3. Xubuntu Jaunty (Xfce4) on sdb5
4. Ubuntu commandline with Fluxbox on sdb1 (USB) - I first encountered it here..

With all of them I got ".dmrc beeing ignored...."

With all of them I fixed it chmod 644 .dmrc and chmod o-w /home/reinhard, which fixed the problem.

And it recurred after I fixed it and after the error message was absent for a while.