Just started getting this emailed.

 

error: Ignoring /etc/logrotate.conf because the file owner is wrong (should be root or user with uid 0).

 

Must be a daily internal crime job of some kind.

Still getting this every day at 04:40.

I assume logrotate is an internal unraid functions - as it is not in my userscripts.

I assume I have to fix up a permission somewhere.

Everything else seems fine - but i guess whatever logs this is trying to rotate, are growing and growing ?

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

I checked /etc, and this file is nobody:users.

As are almost all of the files in /etc.

I assume this is incorrect and these should all be root:root ?

 

 

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

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

 

 

 

Am I right that if I restart unraid, the folders will get re-extracted from the USB stick in memory and then be all as shipped again ?

It that is the case, I have a disk with 430 re-allocated sectors to be replaced soon, and I could do a restart at the same time.

24 minutes ago, vw-kombi said:

Am I right that if I restart unraid, the folders will get re-extracted from the USB stick in memory and then be all as shipped again ?

 

Correct (if nothing else is changing the permissions on you)

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.