http://tinyurl.com/ycm67lt
----- Original Message ----- From: "John Jason Jordan" <[email protected]> To: <[email protected]> Sent: Sunday, December 06, 2009 5:37 PM Subject: Re: [PLUG] It just happened again (Resolved) > On Sun, 06 Dec 2009 15:39:54 -0800 > Dale Snell <[email protected]> dijo: > >>On Sun, 06 Dec 2009 11:30: -320800 >>John Jason Jordan <[email protected]> wrote: >> >>> Thanks for all the suggestions. I finally nailed it. >>> >>> The ~/.local-original/share/applications folder for the new user had >>> only two files. My ~/local/share/applications folder has many >>> entries. I don't know what they do. Some appear to be part of the >>> Applications menu, but others clearly are not. And I also have >>> launchers in Applications that are not reflected in a file in this >>> folder. >>> >>> However, I was especially interested in a file called >>> metacity.desktop. I noted that the new user's original folder did not >>> contain this file. I tried to rename it, but Nautilus would not let >>> me. I certainly own the file and have rw permissions for it, but >>> Nautilus just wouldn't let me. No matter, as root from the command >>> line I renamed it metacity.desktop.old. Then I rebooted. And after >>> logging in metacity launched as it is supposed to. Everything else >>> seems to be working normally. >>> >>> I have no idea what rogue process created this file. >>> >>> It is a text file that can be opened with Gedit. Looking at the >>> contents I see nothing that says "don't launch metacity for this >>> user." >>> >>> If any of the Gnome users on this list have such a file, it would be >>> interesting to compare notes. I feel an obligation to file a bug >>> report, but I in order to make the bug report useful I need to figure >>> out what is the purpose of the file, what created it, and where it >>> went wrong. >>> >> >>John, >> >>I do have the ~/.local/share/applications folder, and the metacity file >>is in it. It's a simple text file. The contents are: >> >>[Desktop Entry] >>Version=1.0 >>Encoding=UTF-8 >>Name=Metacity >>Type=Application >>... >><many lines of the form "Name[<language-specifier>]=Metacity"> >>... >>Exec=metacity >>NoDisplay=true >>X-GNOME-WMSettingsModule=metacity >>X-GNOME-WMName=Metacity >>X-GnomeWMSettingsLibrary=metacity >>X-GNOME-Bugzilla-Bugzilla=GNOME >>X-GNOME-Bugzilla-Product=metacity >>X-GNOME-Bugzilla-Component=general >>X-GNOME-Autostart-Phase=WindowManager >>X-GNOME-Provides=windowmanager >>X-GNOME-Autostart-Notify=true >>Name[en_US]=Metacity >> >>Nautilus shows the filename as "Metacity", but ls shows it as >>metacity.desktop (note the capitalization). Changing the name from the >>command line (mv metacity.desktop metacity.desktop.orig) changed the >>name as shown by ls. Nautilus, however, still showed it as Metacity. >>Changing the name with Nautilus, to Metacity.orig, showed the name >>changed there. Just to be stubborn, ls showed the name as >>metacity.desktop.orig. A little digging showed what is likely the >>reason. >> >>The last line of the file is "Name[en_US]=Metacity". If I change the >>filename using Nautilus, that line changes to >>"Name[en_US]=Metacity.orig". The actual filename, as shown by ls, does >>not change. It seems pretty obvious that this line is what Nautilus is >>reporting as the filename, at least on my system. >> >>Now, as to why Nautilus didn't want to let you change the name of your >>file, I'm not sure. Check the SELinux context for the file, that may >>be a problem. For that matter, check the context for the parent >>directory. I've had trouble occasionally where I couldn't change a >>file, even as root. The security context turned out to be the >>trouble. Here are the directory listings from my system: >> >>[da...@valeron applications]$ ls -d --context ../applications >>drwxr-xr-x dales dales unconfined_u:object_r:user_home_t:s0 >>../applications >>[da...@valeron applications]$ ls --context metacity.desktop >>-rw-rw-r-- dales dales unconfined_u:object_r:user_home_t:s0 >>metacity.desktop >> >>Now that I think about it, SELinux contexts could be a problem waiting >>to bite you. If you're bringing files into Fedora from another distro, >>they almost certainly don't have the right security contexts, assuming >>that they have any at all. Nautilus can set the contexts for you. >>Move to your /home directory and right-click on your user directory. >>Select "Properties" and select the "Permissions" tab. Make sure that >>your folder and file permissions are set correctly (they probably >>are). Then, at the bottom of the panel, you'll see a line "SELinux >>Contexts" and a string widget. Make sure the settings are right >>(again, they probably are, but if not see mine, above), click >>the "Apply Permissions to Enclosed Files" button, and you should be >>good to go. > > The string widget on my Nautilus is just a drop-down, but "User home > directory" > is what it was set to. I did click on the Apply Permissions to Enclosed > Files > button, on general principles. > > I have brought in only a handful of config files from other distros > - .openoffice.org, .scribus, .rhythmbox, and the like. But no config files > relative to the desktop or OS. > > Having said that, I have copied several dozen GB of data from my old > Ubuntu > disk. These are just data files. The interesting thing is that I did so by > dragging and dropping with Nautilus. And I got constant error messages > about > lack of permission. > > The interesting thing is that it was always certain kinds of files, but > not > always. For example, when dragging a folder containing files for books on > Mani > and Kim that I did for a PSU professor, I could copy some PDF files, but > not > others; some TIFF images, but not others, etc. I kept looking for a > pattern, > e.g., were the non-allowed PDFs files that I did not create myself? But > there > was no obvious pattern. > >>That said, I *strongly* suggest reading up on SELinux. I found the >>man pages to be dry and rather rough going, but their info is good to >>have, since Fedora uses SELinux as part of its security setup. >>O'Reilly has a book on SELinux which is easier reading than the Linux >>man pages. >> >>Anyway, I hope that helped. > > It does, although it gives me a lot of work to do. :( > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.426 / Virus Database: 270.14.96/2548 - Release Date: 12/06/09 07:30:00 _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
