error: Ignoring /etc/logrotate.conf because the file owner is wrong


Recommended Posts

Here is the crontab stuff :

 

 

root@Tower:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null


root@Tower:~# cat /etc/cron.d/root
# Generated docker monitoring schedule:
10 0 * * * /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php check &> /dev/null

# Generated system monitoring schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

# Generated mover schedule:
45 3 * * * /usr/local/sbin/mover &> /dev/null

# Generated parity check schedule:
30 0 1 * * /usr/local/sbin/mdcmd check NOCORRECT &> /dev/null || :

# Generated plugins version check schedule:
10 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null

# Generated array status check schedule:
20 0,12 * * * /usr/local/emhttp/plugins/dynamix/scripts/statuscheck &> /dev/null

# Generated Unraid OS update check schedule:
11 0 * * 1 /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null

# Generated cron settings for plugin autoupdates
0 0 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1

# CRON for CA background scanning of applications
35 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1

# Generated ssd trim schedule:
0 5 * * * /sbin/fstrim -a -v | logger &> /dev/null

# Generated system data collection schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null


# Generated schedules for parity.check.tuning
0 23 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
0 10 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
*/7 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
# Generated cron schedule for user.scripts
45 23 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/VW-Daily-FixPermissions-TVRecordings/script > /dev/null 2>&1
*/5 * * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/VW-Sync-Home_Monitoring_to_Hiddeen_Laptop/script > /dev/null 2>&1
30 23 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Weekly-unRAID-4TB-Backup/script > /dev/null 2>&1

Link to comment

I checked my permissions on that file and it is properly 

 1564 -rw-r--r--  1 root root    1875 Jan 25 15:02 logrotate.conf

 

Which implies that something (some script or a container which you're passing /etc (or /) to is adjusting the permissions incorrectly.

 

Basically, nothing in that folder should be nobody:users  It's should be root:root

Link to comment

Thanks @squid.

I did a chown -R root:root * on /etc

 

I have checked other folders for this issue.

 

The 'correct' ones with root:root are sbin, bin, var, boot, lir and run.

/tmp has a mixture of both root and nobody

proc has a mixture of both root and nobody

sys has all folder in there as nobody:users

 

Could I ask if I should do the chown -R root:root * on sys / proc / tmp

 

image.png.1094ca5a5067705c8ac58bf90820056e.png

 

 

Link to comment

Thanks @squid.  My system has been up for ages.  I vaguely remember me issuing a chown for my recorded TV shows but accidentally did not include the target and I aborted it immediately.  I suspect that was the cause at the time.  i had a stork since then however so many memories are now gone, or garbled a bit.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.