copy as root trashes my install

I have had a similar problem. While working in gksudo nautilus, all my icons became generic & the desktop became non-responsive. Upon reboot I was not able to login to my user--I have enabled root on my system & allowed admin logon--that was the only way I could get in my system. I found in my case that /tmp had permissions changed in a way that my user could not write to it--I changed permissions on /tmp & could use again.

I think that nautilus is changing permissions at various places in the system whilst using root.

confirming this problem. I used gksudo nautilus (to access a log file) and got the same errors as Dean reported. The desktop degraded, showing only generic icons, and became non-responsive. On attempting to re-boot, the graphical greeter failed to appear, and attempting to startx after logging in at CL failed. Tried to launch gdm; that failed too, with permission errors.

Any log-files that I could rescue (from Hardy install) before I re-install Intrepid?

here is a copy of .xsession-errors, showing the fatal crash in the last few lines....

it appears that performing some actions as root alters the permissions of "/" to 700 . it is also file roller ( reported by another user in the intrepid forum ) . chmod 755 / restored the system .

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

don't run nautilus using sudo that could be a security issue and that's not recommended

I do not believe that this is a duplicate of bug#238668 . Perhaps my use of the word trashes misled you . I am not reporting a memory leak or any thing about trash .
What I am reporting is that using sudo , GKSUDO nautilus to copy files or running file-roller with sudo ,GKSUDO often results in the permissions of the root partition ( / ) being alterd to 700 causing the system not to boot all the way to GDM. This is not caused by running nautilus with sudo it also occurs with GKSUDO .

Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, this does not appear to be a bug report so we are closing it and converting it to a question in the support tracker. We appreciate the difficulties you are facing, but it would make more sense to raise problems you are having in the support tracker at https://answers.launchpad.net/ubuntu if you are uncertain if they are bugs. For help on reporting bugs, see https://help.ubuntu.com/community/ReportingBugs .

Sebastien--you can be doing almost anything as root & this will occur--I do not believe this a support problem--it seems to be a real problem that has come up with the changes to Nautilus.

the description is not clear enough to constitute an useful bug, if you have precise steps that leads to a broken case please describe in details the actions you do, what you get and why you think that's broken

to reproduce this bug open nautilus in browser mode using sudo or gksudo or gksu and then copy files or open/create an archive with file roller , possibly other actions also . this sometimes but not always results in the permissions on the root directory ( / ) not roots home dir. being changed to 700 which results in a system that will nolonger boot to GDM .

I will try--but as been said, this happens on a ill-regular basis & when it
occurs, the desktop goes to generic icons & will not respond--you need to do
a hard-reboot to get back & it changes permissions in the system. This,
unless you chmod your system--in effect, locks you out of your install.

On Fri, Aug 8, 2008 at 7:48 AM, Sebastien Bacher <email address hidden> wrote:

> the description is not clear enough to constitute an useful bug, if you
> have precise steps that leads to a broken case please describe in
> details the actions you do, what you get and why you think that's broken
>
> --
> copy as root trashes my install
> https://bugs.launchpad.net/bugs/250021
> You received this bug notification because you are a direct subscriber
> of the bug.
>

could you describe a why to trigger the issue when not using file-roller? or how do you know it's not due to this one?

the first tme this occured to me was after copying some files from my /home/user to as subdir in /usr . I had to do the copy as root so on that occasion I used sudo ( bad practice I know ) nautilus to invoke a privlaged nautilus to do the copy. after copying I returned to my /home and attempted to open one of the files ( a script file) and the system froze as described by dean loros . the second time it did involve file roller when I attempted to open an archive from a root nautilus ( this time invoked by gksudo ) . the bug you originaly marked this as a duplicate of bug#238668 refers to a memory-leak with a root nautilus and the trash Icon and nowhere mentions altered permissions or file roller .

I also encountered this bug while using file-roller after using nautilus invoked by gksudo and have encountered bug#238668 before in hardy. The latter caused an almost unresponsive system, while when encountering this bug I didn't experience that, but an inablity to run any programs that were not already open. bug#238668 could be stopped before rendering the system unusable by simply killing nautilus, but this bug didn't give me the ability to even try that (no ability to run programs). It is possible that both stem from the same issue, with super-user privileges involved, but no other direct ties.

as Michael Coupet states when this bug occurs you cannot regain control by killing the root nautilus , infact you cannot kill it because the system is completly unresponsive and only a hard reset or sysreq rseiub will reboot the system and the reboot will not start gdm but leaves you at a terminal login . investigation shows that the permissions for / have ben changed to 700 (root access only) . logging in to the terminal as root if you have a root password set and running chmod 755 / (rwx for root r x for user and others) restores the system to normal .

those comments are still not precise enough to be useful, could you describe steps to trigger the bug?

- boot on an hardy CD
- open a command line
- sudo nautilus
- go to some directory
- copy some other directory there
- notice that the permissions are wrong

something along those lines which allow to work on the issue

First it is NOT HARDY it IS INTREPID IBEX as I cleary stated in the original report . Second it occurs on an hard drive install . As you request I will risk my THIRD fresh install , INTREPID IBEX ALPHA 3 fully updated to august 9 (AM US east coast) to see if I can provide exact steps to reproduce . It may require some time for me to do so since it does not happen every time nautilus is invoked as root . the conditions I use to test are as follows .
1. install to hard drive partitioned as / and home and swap . using alternate install cd .
2 . update using aptitude safe-upgrade daily morning and night.
3 . use the install for all normal daily functions not requiring absolute data integrity .
4. some non default and non OSS aps are installed , Opera browser , flash , acroread ,et cetera.
5 the Nvidia driver (177) from the Ubuntu repos is in use , compiz is in use .

I will post back when I reproduce the bug .

here are the steps by which you can reproduce this bug.
1. in /home/username/subdir using nautilus invoked by gksudo nautilus open a tar.bz2 and extract it .
2. close the root nautilus, close the terminal from which it was invoked .
3. open a user nautilus .
4. watch while system fails .
note ! see attached JPG taken of completely unresponsive desktop , I couldn't do a normal screenshot because at this point only a hard reset or sysreq rseiub is possible .

update: this time I couldn't even alt/sysreq rseiub had to hard reset.

do you get the issue if you run file-roller using sudo and don't use nautilus?

yes I did not have to even open a file with file-roller , just invoking it from terminal " sudo file-roller %u " causes the problem to occur , again the permissions of / are being changed to 700 . logging in as root and running "chmod 755 / " restores the system .

Just happened to me while I was editing menu.lst using gksudo gedit....Found something odd in my syslog.

Aug 9 17:02:31 linux sensord: Sensor alarm: Chip it8718-isa-0290: in5: +0.00 V (min = +0.00 V, max = +4.08 V) [ALARM]
Aug 9 17:03:01 linux pulseaudio[6427]: protocol-esound.c: kicked client with invalid authorization key.
Aug 9 17:03:17 linux last message repeated 4 times
Aug 10 00:03:31 linux sensord: Sensor alarm: Chip it8718-isa-0290: in5: +0.00 V (min = +0.00 V, max = +4.08 V) [ALARM]
Aug 10 00:04:31 linux sensord: Sensor alarm: Chip it8718-isa-0290: in5: +0.00 V (min = +0.00 V, max = +4.08 V) [ALARM]
Aug 9 17:05:31 linux sensord: Sensor alarm: Chip it8718-isa-0290: in5: +0.00 V (min = +0.00 V, max = +4.08 V) [ALARM]
Aug 9 17:06:31 linux sensord: Sensor alarm: Chip it8718-isa-0290: in5: +0.00 V (min = +0.00 V, max = +4.08 V) [ALARM]
Aug 9 17:06:57 linux pulseaudio[6427]: protocol-esound.c: kicked client with invalid authorization key.

Notice the time in the centre---not sure why that happened--that was exactly the time when my icons started to go generic....I had a root terminal window open when it happened & cd'd to / & did a quick chmod 755 & all my icons came back...

Further note--The root terminal window was open with nautilus--I was editing a new test install to test for this problem.

I also have the time jump at the time that the fault occurs , attached are 2 segments from todays syslog showing the times this bug occured , note the time jump ahead and then back.

oops it only added one attachment here is the other

What are you doing Pedro? Can I please encourage you to have a more considered approach if you want to fiddle with bugs? This bug is not invalid, and it certainly is not a low priority issue! This is a very serious problem that trashes the system all together. While there is a workaround, that workaround is non intuitive for novice users who in such a case would be forced into an apparent re-install of Ubuntu. This is certainly the sort of user experience that must be avoided.

If you have some reason why the bug is invalid you need atleast to put a comment as to why and allow us testers to respond.

There is a discussion about this bug going on at:

http://ubuntuforums.org/showthread.php?t=863406&page=1

Can someone with credentials to change the importance / priority please do so.

there is no need to have several tasks open, the issue there seems to be a file-roller one so closing the gvfs task now

Related bug here:

https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/227270

I'd like to elaborate on how this bug has an inappropriate priority since no one with credentials to change it has actioned my suggestion at raising it. I note that another bug that looks at how Intrepid does not shutdown using the shutdown menu in Gnome (workaround is to log out and then shutdown from GDM) has a priority of high. At best, that bug is a nuisance for user workflow.

Here with this bug we have an error that wrecks the system - it nukes the install. The solution requires non intuitive use of the command line. Should this bug pass into production, it could easily lead to Ubuntu users concluding that Ubuntu lacks expected robustness and quality. This bug replicates itself in performing fairly common tasks with file roller.

I expect the priority to be critical. If Ubuntu has a policy statement on the assignment of priorities (which I havent found so far) then I will read/review that.

I agree whole heartedly with Nullack , a bug brought on by a simple common action that locks you out of your system deserves a higher priority than "low" . further the repermissioning of / is bizzare enough that even an experienced user might not find it for awhile and if they did not have the foresight to set a real root password rather than sudo ( which don't work when the bug occurs) his install would be toast .

Sebastian upstream are saying that they have fixed it in their trunk and we can test it anytime you deem Intrepid ready to receive a file roller synch.

marking this as fix committed then.

This bug was fixed in the package file-roller - 2.23.6-0ubuntu1

---------------
file-roller (2.23.6-0ubuntu1) intrepid; urgency=low

  * New upstream version:
    Bugs fixed:
    - #350640: sending an empty folder doesn't work. (lp: #55603)
    - #548020: "create archive" directory selection not working correctly.
        (lp: #230044)
    - #546698: file-roller-2.23.1/2.23.5 removes r/x bit for anyone but
               root from / (lp: #250021)
    - #547733: 7-zip tells about invalid command line
    - #547297: Crash reading zip/7za files with 7z version 4.55.
    - #546978: wrong icon for folders.
    - #547017: segfault in "Open with".
    - #546505: Debian packages not supported anymore. (lp: #258499)
    - #542424: Tar.bz2 archives create uncompressed archive files.
    - #546541: Typo and little errors in documentation.
    - LP#26662: file-roller fails to open .Z files. (lp: #26662)
  * debian/file-roller.mime:
    - new version update
  * debian/patches/70_autoconf.patch:
    - new version update

 -- Sebastien Bacher <email address hidden> Tue, 19 Aug 2008 09:37:02 +0200