zmdisklog cron job fails after upgrade to RHAS5.4

[ple]

Hi,
I went ahead to upgrade my devel. box to RHAS5.4 earlier this morning. After I reboot the server, I keep getting an email from "/opt/zimbra/libexec/zmdisklog" cron job saying that "df: `/dev/sda1': Permission denied". The permission doesn't change as I compared to another box. This is what I get with ls -l "brw-r----- 1 root disk 8, 1 Sep 10 13:18 /dev/sda1"
Thanks in advance,
PL

[milesteg]

Same problem here... This is the result of executing df -H as root user:
[zimbra@mail ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
58849212 21789384 34022236 40% /
/dev/sda1 101086 24230 71637 26% /boot
tmpfs 1037780 0 1037780 0% /dev/shm

However, executing it as user zimbra produces this output:
df: `/dev/mapper/VolGroup00-LogVol00': Permission denied
df: `/dev/sda1': Permission denied

Our OS is RHEL 5.4 (it's been upgraded from RHEL 5.3).

Any ideas?

[milesteg]

Problem solved:

Add user 'zimbra' to 'disk' group.

It works now...

[uxbod]

Please check that SELinux did not get enabled when the upgrade was performed.

[ple]

SELinux is disabled on my devel. system. Now that 5.4 is installed on the production server. The fix from milesteg seems to fix just the sda and sdb volumes on my production box. I'm still getting permission denied from /dev/mapper/volumes. Any suggestion?
Thanks.
PL

[victorf]

SELinux is disabled on my devel. system. Now that 5.4 is installed on the production server. The fix from milesteg seems to fix just the sda and sdb volumes on my production box. I'm still getting permission denied from /dev/mapper/volumes. Any suggestion?
Thanks.
PL

Are you running RHEL 5.4 64bit by any chance?

While Adding the zimbra user to the disk group on the 32bit test box was the sufficient solution, the same didn't work on the 64bit production box.

Bare in mind that I'm not sure this is the proper way to fix this issue, but it seems that this is the only script "zmdisklog" run via crontab that gets the "Permission denied" error trying to run df against the /dev/mapper/VolGroup00-LogVol0** entry after the RHEL 5.4 update.

Anyway, here is what I did as a quick fix to resolve it:

1- Add a line in sudo (via visudo) for the "zimbra" user as follows:

%zimbra ALL=NOPASSWD:/opt/zimbra/libexec/zmdisklog

2- Modify the zimbra crontab to add the sudo command to the zmdisklog line:

*/10 * * * * sudo /opt/zimbra/libexec/zmdisklog

# You should test the command above by hand as the zimbra user before modifying the crontab to make sure it works the way it should.

## The examples here assume that you have your software installed under the default /opt/zimbra path

[mattg1]

I have the same issue, but if you look in the logs, the cron job is still working, but it is generating some extra output to stderr due to zmdisklog doing a "df" on the device files, rather than the mount points. For some reason in Redhat 5.4, non-root users cannot read the device files by default.

Looking at line 81 in the perl script /opt/zimbra/libexec/zmdisklog , "df" is being run on the device file ($dev) which is what generates the error. But then on line 85 it proceeds to run "df" on the mount points ($mp) which succeeds. I'm not sure why the script does it twice... probably an oversight.

If you feel brave you could try commenting out lines 81-83 and that should remove the error.

-Matt

[cubittech]

I have the same issue, but if you look in the logs, the cron job is still working, but it is generating some extra output to stderr due to zmdisklog doing a "df" on the device files, rather than the mount points. For some reason in Redhat 5.4, non-root users cannot read the device files by default.

Looking at line 81 in the perl script /opt/zimbra/libexec/zmdisklog , "df" is being run on the device file ($dev) which is what generates the error. But then on line 85 it proceeds to run "df" on the mount points ($mp) which succeeds. I'm not sure why the script does it twice... probably an oversight.

If you feel brave you could try commenting out lines 81-83 and that should remove the error.

-Matt

I have this exact issue and am going to try this fix. I'll let you know if it works.

[ple]

I've got to be honest; I'm not that brave to try it on a prod. box. Unfortunately, my devel. box doesn't have logical volumes. Anyhow, I'd appreciate if you could share the results. By the way, this, according to Zimbra, is a bug. You can track it from here.
Thanks.
PL

[cubittech]

I can confirm that commenting out lines 81-83 of /opt/zimbra/libexec/zmdisklog seems to fix the problem on one of my systems.

I have not observed any unwanted side effects.

Many thanks.
Guy