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.

[GNUser]

a quick glance at  filetool.sh
shows it's riddled with  sudo  commands.

It makes sense it would need sudo. filetool.sh is run as regular user but it restores items to directories owned by root (e.g., /etc).

I think that if filetool.sh is doing a restore operation and if it touches user's /home directory, then filetool.sh needs to take responsibility and make sure it doesn't leave behind anything owned by root inside of /home. I propose changing this part of /usr/bin/filetool.sh:

Code: [Select]

if [ "$RESTORE" ] ; then
...
  clean_up 0
fi

to this:

Code: [Select]

if [ "$RESTORE" ] ; then
...
  read USER < /etc/sysconfig/tcuser
  if grep -Eq "^/?home/$USER" /opt/.filetool.lst; then
    sudo chown -R "$USER":staff /home/"$USER"
  fi
  clean_up 0
fi
Any objections? Should I create a pull request on github?

P.S. I tested the proposed change to filetool.sh and
  1. I see no more root-owned directories in my /home
  2. The "mkdir" error during boot went away
  3. No more workarounds are needed
      3a. no chown line in ~/.profile
      3b. I can backup whatever I want in /home (including /home/bruno/.local/share/foo) without it causing problems

[Rich]

Hi GNUser
This almost sounds like a bug in busybox tar:

Code: [Select]

tc@E310:~$ busybox tar --help
BusyBox v1.29.3 (2018-12-19 15:29:37 UTC) multi-call binary.

Usage: tar c|x|t [-ZzJjahmvokO] [-f TARFILE] [-C DIR] [-T FILE] [-X FILE] [--exclude PATTERN]... [FILE]...

Create, extract, or list files from a tar file

        c       Create
        x       Extract
        t       List
 ----- Snip -----
        -m      Don't restore mtime
        -o      Don't restore user:group <------- If this isn't used, user:group should be preserved.
 ----- Snip -----
Could you check if GNU tar exhibits the same behavior?

[Rich]

Hi GNUser
Some Googling about tar suggests ownership/permissions are
supposed to be preserved when extracting as root.

When creating a tarball, ownership/permissions are supposed
to be preserved regardless of who runs the command.

[GNUser]

Hi Rich. If  filetool.sh -r  uses GNU tar, it makes no difference (i.e., I still end up with things owned by root in my home directory):

Code: [Select]

$ ls -ld .config
drwxr-sr-x   15 bruno    staff          500 Sep  8 10:21 .config

$ tce-load -i tar
tar.tcz: OK

$ sudo sed -i 's|/bin/tar|/usr/local/bin/tar|g' /usr/bin/filetool.sh

$ 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  8 10:22 .config

[GNUser]

Hi GNUser
Some Googling about tar suggests ownership/permissions are
supposed to be preserved when extracting as root.

When creating a tarball, ownership/permissions are supposed
to be preserved regardless of who runs the command.

Hi Rich. I think Google is wrong here. Do this little experiment:

Code: [Select]

$ mkdir $HOME/test1
$ cd $HOME/test1
$ cp /etc/sysconfig/tcedir/mydata.tgz ./
$ tar -xvf mydata.tgz

$ mkdir $HOME/test2
$ cd $HOME/test2
$ cp /etc/sysconfig/tcedir/mydata.tgz ./
$ sudo tar -xvf mydata.tgz
- In test1 you will see that the items extracted from mydata.tgz are owned by your normal user
- In test2 you will see that the items extracted from mydata.tgz are owned by root
- I repeated test1 and test2 with GNU tar and got the same results

I'm finding that if I use sudo to extract a tarball, the extracted contents end up being owned by root. I think my proposed change to /usr/bin/filetool.sh (in Reply #7) might be the best way to go.

[Rich]

Hi GNUser
Does this show ownership/permissions were preserved
when creating the tarball:

Code: [Select]

tar -vtf /etc/sysconfig/tcedir/mydata.tgz

[patrikg]

Code: [Select]

     -p, --preserve-permissions, --same-permissions
            Set permissions of extracted files to those recorded in the archive (default for  supe‐
            ruser).

     --same-owner
            Try  extracting files with the same ownership as exists in the archive (default for su‐
            peruser).

[GNUser]

Hi GNUser
Does this show ownership/permissions were preserved
when creating the tarball:

Code: [Select]

tar -vtf /etc/sysconfig/tcedir/mydata.tgz

Yes, it does:

Code: [Select]

$ tar -vtf /etc/sysconfig/tcedir/mydata.tgz
lrwxrwxrwx root/root         0 2026-09-07 15:49 etc/fonts -> /usr/local/etc/fonts
-rw-rw-r-- root/staff       95 2025-02-03 08:48 etc/group
-rw-rw-r-- root/staff       93 2024-12-06 08:39 etc/resolv.conf
...
-rw-r--r-- bruno/staff     364 2024-01-21 10:10 home/bruno/.config/easymail.conf
-rw-r--r-- bruno/staff     208 2026-07-21 14:07 home/bruno/.config/easyprint.conf
drwxr-sr-x bruno/staff       0 2026-09-07 15:49 home/bruno/.config/feh/
...
drwx--S--- bruno/staff       0 2026-09-07 15:49 home/bruno/.local/share/profanity/
-rw------- bruno/staff     591 2026-08-10 11:13 home/bruno/.local/share/profanity/accounts
-rw------- bruno/staff     485 2026-08-10 11:05 home/bruno/.local/share/profanity/capscache
drwx--S--- bruno/staff       0 2026-09-07 15:49 home/bruno/.local/share/profanity/database/