Clamav update takes ownership of the users home directory thus preventing booting into gnome desktop.

[Tigerboy]

Would not boot into normal Gnome desktop as I would get a failure message instructing me to set user permissions. Couldn't get into grub single mode as the system didn't start with a standard grub menu, just proceeds to the boot up graphic.

Problem found and solution discovered: I switched to Gnome safe mode and finally got in. I changed the ownership of the users home directory which you can do by going to "cd /home" and ls -l to find the current ownership which had been taken over by clamav, apparently clamav, during it's last update, took possession of the users home directory which caused the failure to boot ( user's home directory is the directory which is in the /home directory and has the same name you log on with. "username" = the name you log on with.). Whilst in the "/home" directory at the command line simply type "chown username:username username" and finally "chmod 0755 username". This will change the owner and group to "username" and should solve the problem caused by the bad clamav installation.

The version of clamav was the one available for update on April 29 2009. I am not sure if that is version clamav 0.95.1+dfsg-1ubuntu1.1 or it is the one just before it as I ran an update following this successful fix and wasn't certain if it had been updated. I'll be more careful next time. Clamav became "owner" and the username retained group however it had no write powers.

[Steve (stupendoussteve-deactivatedaccount)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we can't fix it because your description didn't include enough information.

Please let us know the version of clamav that appears to have caused this issue, along with any more information which could assist in debugging the package.

[Tigerboy (tigersands)]

The version of clamav was the one available for update on April 29 2009. I am not sure if that is version clamav 0.95.1+dfsg-1ubuntu1.1 or it is the one just before it as I ran an update following this successful fix and wasn't certain if it had been updated. I'll be more careful next time. Clamav became "owner" and the username retained group however it had no write powers.

[Scott Kitterman (kitterman)]

No. I know exactly what this is. We are working on a fix. Please confirm
you have the clamav-milter package installed?

[Scott Kitterman (kitterman)]

It was 0.95.1+dfsg-1ubuntu1 that introduced the problem.

[Steve (stupendoussteve-deactivatedaccount)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 365823, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.

[Tigerboy (tigersands)]

Yes clamav-milter is installed. Did the update yesterday evening, no reboots, when that system was started this morning it failed as specified above.

[Scott Kitterman (kitterman)]

Then you are definitely having the bug this is dup'ed to.

[Tigerboy (tigersands)]

ok when selecting clamav in the Ubuntu package manager it adds clamav-milter. Prior to April 29 2009 update of this ubuntu 9.04 final workstation this was not a problem so I thought it was a new bug. It was the clamav update included with the updates of that day that caused the permissions ownership change of the users home directory. This particular system had successfully migrated from ubuntu 8.10 using ubuntu's upgrade system a week or so prior and there were daily updates without this problem. It was the booting up on the 30th after the update of the 29th that exhibited the failure to boot. Hence I reported the bug on the 30th.

[Tigerboy (tigersands)]

In checking the bug that you say this bug is a dup of I find it is not a dup at all. The problem occurred after an upgrade of Ubuntu which included the Clamav update and then shutdown and booting. The root folder had no permissions or ownership changes. I received a notice with an ok button that the file .dmrc was not writable and should be owned by the user hence I couldn't boot into normal gnome desktop. I was able to boot using the failsafe gnome desktop option when I discovered that the users home directory had been taken over ownership at the owner level by clamav... group remained the username. That is the folder /home/username was taken over by clamav and thus prevented normal booting to the full gnome desktop. It prevented booting because the file .dmrc was in the users home directory and the group although it remained the username didn't have write permissions.

This is not at all the same bug.

[Scott Kitterman (kitterman)]

Depending on how the clamav-milter init is executed, different directories can be affected. I'm confident it's the same bug. As part of working on fixing this bug, I reviewed every ownwership change in the clamav maintainer scripts and the rest appear OK.

It looks like we'll have a fix out on Monday.

[Tigerboy (tigersands)]

Still it's not the same bug from a user standpoint. The standard way of updating runs the update as root which, in this case, prevented the system from booting to desktop.

What you are saying is that the bug reports purpose is exclusively to report general bugs to core or packages teams and not to provide any searchable utility to end users then I misunderstood that although I disagree with it.

[Scott Kitterman (kitterman)]

The same issue is at the root of the problem. If you feel the description
of the primary bug is insufficient to encompass the way it affected your
system, please feel free to edit the bug description to add the information
you feel is missing.

[Steve (stupendoussteve-deactivatedaccount)]

Good day,

As I responded to your email message, the purpose of these bug reports is primarily to alert the developers. Users are encouraged to search for bug reports because, in finding the report and the work being done to fix it (and exactly what was done that made it a bug), they may be able to find a work around. It is not intended to be a knowledge base necessarily, and users searching for an issue may often find answers such as "Fixed in new version", which doesn't tell them how to fix it at the moment.

I have updated the description of the primary bug to better reflect that any directory may be affected by the bug. This should hopefully assist users with searching for the issue.

If users are mentioning similar symptoms through the support mechanisms, it may not be a bad idea to comment "It sounds like you may be affected by bug 369986, here is how to fix it:", this is a relatively common response. If the issue comes up enough, there is a knowledge base in the Answers system where you may put the exact steps, but I don't think it is going to be extremely common (at least, I don't think users will notice much if it is, since usually the / directory ends up with new ownership).

Thanks

[Tigerboy (tigersands)]

thanks it's a separate bug and it happens just by updating or installing the clamav and it causes a separate problem which requires a unique solution. I just don't understand why a package, even an antivirus, would need to take possession of a critical directory when everyone uses root to install updates. But that's another issue. I'll add this to the other bug if it hasn't been already.
thanks

[Imre Gergely (cemc)]

It doesn't need to take posession of any critical directory, that's exactly the problem, and that's why this bug is duplicate of bug #365823.

When clamav-milter init script is run (/etc/init.d/clamav-milter start/restart), because of a bug in the script, the current directory gets chown'd to clamav. So if you run this script as user from your home directory with sudo, your home directory gets chown'd to clamav. If you run it as root, the '/' gets chown. If you run in from /etc, /etc gets chown'd.

I would think one runs the update manager with sudo, that means even if it runs as root, the current directory may be the user's home directory. After the package update, the above buggy clamav-milter script gets run = user's home gets chown'd to clamav.