boot error: mkdir "/home/bruno/.local/bin" Permission denied

[GNUser]

I'm on TCL17.1 x86_64. My home directory is not persistent and I use the  user=bruno  bootcode.

TL;DR version: Just read the last paragraph of this post.

I see this error during boot:

Code: [Select]

mkdir: "/home/bruno/.local/bin" Permission denied

Something similar has been previously reported (https://forum.tinycorelinux.net/index.php?topic=16036.15) but I think what I'm experiencing is a bit different than what's described at the link.

There are two places during boot where something to the effect of  mkdir ~/.local/bin  appears:

1. the  setupHome  function (which is called in /etc/init.d/tc-config but defined in /etc/init.d/tc-functions), which contains this line:

Code: [Select]

      mkdir -p /home/"$USER"/.local/bin

2. this line in ~/.profile:

Code: [Select]

[ -d "$HOME/.local/bin" ] || mkdir -p "$HOME/.local/bin"

setupHome is innocent here because  /home/"$USER" already exists when setupHome is called, so the  then  part of the  if-then  that contains the  mkdir  statement is not executed.

I can confirm that the  mkdir  that's causing the error during boot is the one in ~/.profile

After boot process is complete, it's no wonder the mkdir statement (which is in ~/.profile so run by normal user, not root) fails:

Code: [Select]

$ ls -ld $HOME/.local
drwxr-sr-x    3 root     staff           60 Sep  7 14:07 /home/bruno/.local

$ find $HOME -user root -type d
./.local
./.local/share

I have found two workarounds.

First workaround is to change this in ~/.profile:

Code: [Select]

[ -d "$HOME/.local/bin" ] || mkdir -p "$HOME/.local/bin"
to this:

Code: [Select]

sudo chown -R $(cat /etc/sysconfig/tcuser):staff "$HOME/.local"
[ -d "$HOME/.local/bin" ] || mkdir -p "$HOME/.local/bin"
Second workaround is to edit my /opt/.filetool.lst and make sure nothing from ~/.local/share is included. For example, if my /opt/.filetool.lst looks like this

Code: [Select]

etc/fonts
etc/group
etc/resolv.conf
etc/shadow
etc/ssl
etc/thunderbird
home/bruno/.local/share/profanity
then I see the mkdir error during boot. But if I change /opt/.filetool.lst to just this

Code: [Select]

etc/fonts
etc/group
etc/resolv.conf
etc/shadow
etc/ssl
etc/thunderbird
and create a new backup (filetool.sh -b), then the  mkdir  error during boot goes away.

I'm perplexed by this second workaround. Anything I include in my backup in the form of /home/bruno/.local/share/foo (no matter what it is, no matter that everything along the path is owned by bruno:staff) causes /home/bruno/.local and /home/bruno/.local/share to be owned by root and the mkdir error during boot. Any ideas what's going on here?

[patrikg]

Hi GNUser

Strange, that this don't fire in file tc-functions line 216 from tc-config line 462:

Code: [Select]

setupHome(){
   read USER < /etc/sysconfig/tcuser
   if [ ! -d /home/"$USER" ] || [ "`ls -la /home/${USER} | wc -l`" -le 3 ]
   then
      mkdir -p /home/"$USER"/.X.d
      mkdir -p /home/"$USER"/.local/bin
      chown -R "$USER":staff /home/"$USER/"
      chmod -R g+s,o-rwx /home/"$USER/"

With the line

Code: [Select]

chown -R bruno:staff /home/brunoThat's sets the bruno:staff recursive down to .local/bin

Why not generate a new initrd with the line in tc-config

Code: [Select]

#!/bin/busybox ash
set -ex
So you can see with your own eyes whats going on.
Maybe some extension writes to that directory with wrong rights.
Or your backup has wrong rights to that directory.

And run the tool like this so you see whats files being copied/backed up via

Code: [Select]

filetool.sh -bv
Or do run a app(like profanity) with sudo that's writes some files under your home.

[GNUser]

Maybe some extension writes to that directory with wrong rights.
Or your backup has wrong rights to that directory.

That's not it.

I created a fresh frugal install, very barebones:
- nothing in  tce/onboot.lst  other than  graphics-KERNEL.tcz
- nothing in  /opt/.filetool.lst  other than  home/bruno/.local/share/empty.txt
- nothing in  tce/mydata.tgz  other than  /home/bruno/.local/share/empty.txt

When I boot this barebones setup, I see the  mkdir  error during boot.

I was wondering if Juanito or Rich could try to reproduce the  mkdir  error I'm seeing during boot? I think all you need to do is add an empty file  /home/tc/.local/share/empty.txt  to your backup.

[GNUser]

I'm getting warmer.

On a totally barebones system (as described in my prior post, "Reply #2"), bug only occurs if:
1. you use  user=someone  bootcode
and
2. your /opt/.filetool.lst contains any  home/someone/.local/share/foo

Then, ~/.local and ~/.local/share are both owned by root and the mkdir error appears during boot.

If I remove the  user=foo  bootcode, then ~/.local is owned by tc:staff and there is no mkdir error during boot (but ~/.local/share is still owned by root).

I'll keep investigating. I think I'm close to finding the bug.

[Rich]

Hi GNUser
I think I found something. Not sure what it is, but it looks related.

About 1/3 of the way into  tc-config  there is this:

Code: [Select]

if [ -n "$USER" ]; then
        if ! grep "$USER" /etc/passwd >/dev/null; then addUser; fi
else                                                     
        USER="tc"
fiSince you specify a user, it takes the  grep  path.
Since you are not yet in  /etc/passwd , addUser  gets called.

Then near the end of  tc-config  your restore occurs:

Code: [Select]

if [ -n "$NORESTORE" ]; then
        echo "${GREEN}Skipping restore as requested from the command line.${NORMAL}"
else
        TCEDIR=`readlink /etc/sysconfig/tcedir`
        /etc/init.d/tc-restore.sh "$TCEDIR"
fi                                 
Even if your  passwd  file were backed up, it would be too late.

Apologies in advance if this sounds like a dead end, I'm a little tired right now.

By the way, what else is in  home/bruno/.local/share  ?

Maybe nothing is changing  home/bruno/.local/share  to  root.
Maybe  home/bruno/.local/share  isn't being changed to  bruno
like other directories are.

[GNUser]

By the way, what else is in  home/bruno/.local/share  ?

Hi Rich. In my minimal test system (just base + graphics-KERNEL.tcz + the single empty file in mydata.tgz), nothing else is in home/bruno/.local/share.

Maybe nothing is changing  home/bruno/.local/share  to  root.
Maybe  home/bruno/.local/share  isn't being changed to  bruno
like other directories are.

Yes, I think this is it. See below.

Here is a terminal session on my daily driver laptop, with some surprising results:

Code: [Select]

$ ls -ld .config
drwxr-sr-x   15 bruno    staff          500 Sep  7 21:57 .config
$ rm -rf .config
$ filetool.sh -r
Restoring backup files from /mnt/sda1/tce/mydata.tgz Done.
$ ls -ld .config
drwxr-sr-x   15 root     staff          480 Sep  7 21:57 .config
Note how the initial  .config  directory (created during boot from my backup) is owned by  bruno:staff, but the one created by  filetool.sh -r  is owned by  root:staff!

I didn't realize that  filetool.sh -r  leaves things in my home directory as owned by root. This seems like a bug in filetool.sh. Maybe Shingledecker did not foresee weirdos like me using filetool.sh to backup/restore things in my home directory (because my home directory is not persistent).

I have 2 million-dollar questions:

1. During boot there must be a step after  tc-restore.sh  that changes ownership of my home directory's contents to "bruno." Do you know what that step is?

2. It seems the boot step that changes ownership of things in home directory to $USER is missing ~/.local for some reason. Could the change to ~/.profile I mentioned in my original post be considered a proper fix?

[Rich]

Hi GNUser

... I didn't realize that  filetool.sh -r  leaves things in my home directory as owned by root. ...

I've never really looked at it before, but a quick glance at  filetool.sh
shows it's riddled with  sudo  commands.