[PLUG] It just happened again (Resolved)

Tom Sharples tsharples at qorvus.com
Mon Dec 7 02:53:50 UTC 2009


http://tinyurl.com/ycm67lt

----- Original Message ----- 
From: "John Jason Jordan" <johnxj at comcast.net>
To: <plug at lists.pdxlinux.org>
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 <ddsnell at verizon.net> dijo:
>
>>On Sun, 06 Dec 2009 11:30: -320800
>>John Jason Jordan <johnxj at comcast.net> 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:
>>
>>[dales at valeron applications]$ ls -d --context ../applications
>>drwxr-xr-x  dales dales unconfined_u:object_r:user_home_t:s0 
>>../applications
>>[dales at 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
> PLUG at lists.pdxlinux.org
> 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




More information about the PLUG mailing list