Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: GNUser on September 07, 2026, 03:40:31 PM
-
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:
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:
mkdir -p /home/"$USER"/.local/bin
2. this line in ~/.profile:
[ -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:
$ 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:
[ -d "$HOME/.local/bin" ] || mkdir -p "$HOME/.local/bin"
to this:
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
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
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?
-
Hi GNUser
Strange, that this don't fire in file tc-functions line 216 from tc-config line 462:
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
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
#!/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
filetool.sh -bv
Or do run a app(like profanity) with sudo that's writes some files under your home.
-
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.
-
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.
-
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:
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:
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.
-
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:
$ 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?
-
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.