File/Directory ownerships changed in /home after reboot

[Rich]

This happens under both TC3.8.4 and TC4.1 with a persistent /home. I was building an extension under /home/tc/nvidia
and I noticed that the  nvidia/...../local/tce.installed  directory and the file under that have their ownerships changed from
root:staff  to  tc:staff  after rebooting. There no references to  home in my  /opt/.filetool.lst file. I was wondering if this was
the intended behavior?

[shail.dw]

When at the stage of your going to create the shell script (i.e. /tmp/package/usr/local/tce.installed/your_package_name) in the final stages of your extension creation,  did you followed the following two steps first :

chown -R root:staff /tmp/package/usr/local/tce.installed
chmod -R 775 /tmp/package/usr/local/tce.installed

For the first step you would need to be root ! Did not you fail to do that and proceeded without noticing the failure message. Or you might have omittted to take that precaution outright.

Conversely, what were your user rights, till you came to the step of creating the above shell script: tc, or root?

Otherwise root's directory changing ownership is impossible.

[Rich]

Hi shail.dw
Yes, I used  sudo  when I changed ownership to  root:staff. One of the Tinycore startup scripts is changing it back
to  tc:staff  every time I reboot.

[shail.dw]

If so, though very unprobable, why not check first /opt/bootsync.sh and /opt/bootlocal.sh, especially the former one ? If possible check before rebooting, and after then before rebooting (i.e. through another OS, not through Tinycore !). You say that after reboot there are no references to home in your /opt/.filetool.lst file. So something is going on in /opt itself. check also .xfiletool.lst. Then you may report back to me.

[shail.dw]

Or, try this:

mv /opt /opt_original (I am sure you have a persistent opt; you can reverse the change later and get back your original opt)
remove opt= from boot option
add opt to .filetool.lst
(check if by any mistake opt has not made entry in .xfiletool.lst)
reboot
All that can be reversed later.

Delete everything of the old files and directories of previous work done. Do the process of extension creation afresh. Reboot to check the result.

I again assert that root's directory cannot change ownership, but add this: "without root itself doing that" ! Are you booting/rebooting as/into root !?

[Rich]

Hi shail.dw

You say that after reboot there are no references to home in your /opt/.filetool.lst file.

No, I said  "There no references to  home in my  /opt/.filetool.lst file", period. That's because I don't run backup or
restore on my  /home  directory, because it's persistent.

I again assert that root's directory cannot change ownership

The system startup scripts run as root.

I think it's the  setupHome()  function in tc-funtions that's doing this. It contains a recursive  chown  command
for  /home/"$USER"/

[shail.dw]

Hi Rich

I exactly mistook you, when I erroneously concieved that one of your entry in opt (the entry home) was getting changed/deleted during reboot. I will correct myself from this wrong view in my next consideration.

In my assertion that root's files cannot change ownership, didn't I added "without root itself doing that" ? That is clear as daylight. In this there was no denial that startup scripts run as root, instead I was confirming what you yourself suspected, that some startup script is in interference. For the same reason I queried if you were not booting to a root console, which is possible through setting up the relevant boot parameter .

Anyhow, I saw that your original post was unanswered for some time, and so I suggested. You have come out with a possible interpretaion yourself, i.e. giving a lookup for SetupHome () function in tc-functions. I will dig into it after you. It is worth scrutiny. But I also suggested that you try through a "pristine state of Tinycore".

I always boot to that pristine state of Tinycore, through another boot entry in my bootloader (legacy grub), where I don't have any opt= and home= kernel parameters, keeping tce=same_for_all_boot_entries, and besides having mydata=some_another_filename_than_the_one_where_this_backup_is_done_when_I_boot_otherwway .  This way I am always able to test, if it is "Pristine state of Tinycore" which is the culprit, or something else. It is also one method of trapping/finding the source(s) of error, when one has Tinycore to work with. "Pristine state", that is a boon with tinycore.

Anyhow Rich, I will give a look to what you yourself have come out with, besides seeking for other plausibilities.