[Solved] why does boot process change /opt ownership to root?

[GNUser]

I use the  opt=sda3  and  user=bruno  boot codes. Boot process consistently changes ownership of the /mnt/sda3/opt directory to root for some reason:

Code: [Select]

$ sudo chown bruno /mnt/sda3/opt
$ ls -ld /mnt/sda3/opt
drwxrwsr-x    8 bruno    staff         4096 Mar 30 02:45 /mnt/sda3/opt/
$ sudo reboot
...wait for system to reboot...
$ ls -ld /mnt/sda3/opt
drwxrwsr-x    8 root     staff         4096 Mar 30 02:45 /mnt/sda3/opt/

I recursively grep'ed through /etc for both "chown" and "/opt" and did not find any clues as to how or why this happens. Any ideas?

[jazzbiker]

Hi, GNUser!

I think, that /opt is the native part of rootfs.gz with root:staff owner, and it is filled during boot process without changing the ownership. How about this explanation?

[GNUser]

Hi, jazzbiker! As always, thanks for your input.

What you're saying would explain root ownership of /opt but not the changed ownership (from bruno to root) of /mnt/sda3/opt.

To make my observation more concrete: If I shutdown TCL, boot into a different OS on same harddisk, and check the ownership of /mnt/sda3/opt, I still see that the ownership has been changed to root:staff.

[jazzbiker]

Hi, GNUser!

Its amazing, I can say nothing yet on such behaviour :-(
Besides I've found funny trick which allows to change directory ownership during "tared" restore using -T "some.list". For example, if Your "some.list" conatins

Code: [Select]

opt
then ownership will be unchanged, but in case Your "some.list" contains

Code: [Select]

opt/../opt
ownership is updated.

I checked this trick only in the sandbox, not for full the shutdown-boot TC cycle.
According to Your refinement, sad but if You need to change ownership for some other OS use, this will not help.

[GNUser]

Hi, jazzbiker. That's some funky  tar  behavior your discovered. Thanks for sharing

I found a section in  /etc/init.d/tc-config  that handles  OPT_SETUP  via the  MYOPT  variable. Nothing in that section seems to account for the change in ownership.

This is not a big deal, by the way. I'm just trying to understand it because I don't like unexplained behaviors.

[jazzbiker]

Of course, its normal to understand wats going on inside Your box, I totally agree with Your intentions, thanks for asking not-obvious questions, helping to clear some hidden ways.
But as I understand Your description, the named ownership change took place not during boot, but during shutdown. Don't You quess so?

[GNUser]

not during boot, but during shutdown. Don't You quess so?

Huh. I was assuming during boot but I guess it could be during shutdown. I'll do some experiments to prove which one. Stay tuned.

[GNUser]

Boot process is definitely the culprit. TCL shutdown process does not change ownership of /mnt/sda3/opt:

Code: [Select]

TCL$ sudo chown bruno /mnt/sda3/opt
TCL$ ls -ld /mnt/sda3/opt
drwxrwsr-x    8 bruno    staff         4096 Mar 30 02:45 /mnt/sda3/opt/
TCL$ sudo poweroff
...boot into a different OS, mount the sda3 partition, cd to the mounted sda3 partition...
Devuan$ ls -ld opt
drwxrwsr-x    8 bruno     staff         4096 Mar 30 02:45 opt

[jazzbiker]

Hmm... then the trick i'm proposing may help. If You want i will check it by myself, in order not to make the troubles for You. But I don't use any persistance, so I will do this  a little bit later after some preparations, Ok?

[GNUser]

Thanks, jazzbiker, but a simpler fix would be to add "sudo chown bruno /mnt/sda3/opt" to my startup jobs in ~/.X/

I'm not necessarily trying to fix the issue, just understand what's going on. If I do fix the issue, I'd like to fix it by changing the part of the boot process that's responsible for it.

[jazzbiker]

Ok, Your way is more straightforward thus the better one, agree. If talking about understanding, I hope we'd got it :-) Thanks for Your questions, digging and contributing to finest OS ever ! :-)

[GNUser]

I finally figured it out. The culprit is line 470 of /etc/init.d/tc-config, which looks like this:

Code: [Select]

    yes n | cp -ai /opt/. "$MOUNTPOINT"/opt/ 2>/dev/null
The purpose of the line is to copy the files below from core.gz's /opt to user's custom /opt, but only if the files don't already exist in the latter:

Code: [Select]

.filetool.lst   
bootlocal.sh   
shutdown.sh
.xfiletool.lst
bootsync.sh   
tcemirror
However, a side effect of the command is that it changes ownership of user's custom /opt directory. Since /opt is my only persistent directory (I don't use or want a persistent home directory), this side effect a) bothers me tremendously and b) forces me to use sudo when restoring my TCL system (which consists of just the opt, boot, and tce directories) from a network backup.

Replacing the offending line (line 470 in /etc/init.d/tc-config) with these two lines does what the command was intended to do, without the undesirable side effect:

Code: [Select]

   
    yes n | cp -ai /opt/* "$MOUNTPOINT"/opt/ 2>/dev/null
    yes n | cp -ai /opt/.[!.]* "$MOUNTPOINT"/opt/ 2>/dev/null

If possible, please include this fix in future releases.

[jazzbiker]

Hi, GNUser!

But after copying Your persistent /opt is mounted:

Code: [Select]

mount --bind "$MOUNTPOINT"/opt/ /opt/
and in this case /opt will have bruno:staff ownership. It is not very correct for other users, lets imagine that they exist. /opt is system-wide stuff, and changing its ownership may have other side effects, which will appear later. Isn't restoring of Your persistent opt ownership better?

Never seen

Code: [Select]

cp <dir>/. yet, thanks for this attraction :-)

[GNUser]

in this case /opt will have bruno:staff ownership. It is not very correct for other users, lets imagine that they exist. /opt is system-wide stuff, and changing its ownership may have other side effects, which will appear later.

That's a good point, jazzbiker, which I failed to consider. Maybe this is best left alone.

Thread may be marked as Solved since now we now exactly which command changes the ownership.

[Rich]

Hi GNUser

... Thread may be marked as Solved ...

So marked.