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.
-
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:
if [ "$RESTORE" ] ; then
...
clean_up 0
fi
to this:
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
-
Hi GNUser
This almost sounds like a bug in busybox tar:
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?
-
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. 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):
$ 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
-
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:
$ 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.
-
Hi GNUser
Does this show ownership/permissions were preserved
when creating the tarball:
tar -vtf /etc/sysconfig/tcedir/mydata.tgz
-
-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).
-
Hi GNUser
Does this show ownership/permissions were preserved
when creating the tarball:
tar -vtf /etc/sysconfig/tcedir/mydata.tgz
Yes, it does:
$ 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/
-
Rich, did you try my simple experiment in Reply #11? It would be good to know that someone can reproduce what I'm observing with tar vs. sudo tar
-
Can you also see that what tar is being used with backup vs restore ?
sudo tar (maybe busybox or gnu)
Maybe ?
which -a tarAnd:
sudo which -a tar
-
ON GNU
Compatibility options
-o When creating, same as --old-archive. When extracting, same as --no-same-owner.
ON BUSYBOX
-o Don't restore user:group
-
Hi Rich. I think I figured it out what's going on here. Follow along:
$ ls -ld .config
drwxr-sr-x 15 bruno staff 500 Sep 8 11:17 .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 8 11:17 .config
$ cd .config
~/.config$ ls -l
...
drwxr-xr-x 2 bruno staff 60 Sep 8 11:17 asunder
drwx--S--- 2 bruno staff 60 Sep 8 11:17 dconf
-rw-r--r-- 1 bruno staff 364 Jan 21 2024 easymail.conf
-rw-r--r-- 1 bruno staff 208 Jul 21 14:07 easyprint.conf
drwxr-sr-x 2 bruno staff 60 Sep 8 11:17 feh
drwxr-sr-x 2 bruno staff 60 Sep 8 11:17 foot
drwx------ 6 bruno staff 180 Sep 8 11:17 geany
drwxr-xr-x 2 bruno staff 60 Sep 8 11:17 gtk-3.0
...
Note how when filetool.sh -r runs, my .config directory ends up being owned by root:staff but its subdirectories are owned by bruno:staff
I think tar is working as advertised: I do not have /home/bruno/.config in /opt/.filetool.lst--I only have its subdirectories:
$ cat /opt/.filetool.lst
...
home/bruno/.config/asunder/
home/bruno/.config/dconf
home/bruno/.config/easymail.conf
home/bruno/.config/easyprint.conf
home/bruno/.config/feh/
home/bruno/.config/foot/
home/bruno/.config/geany
home/bruno/.config/gtk-3.0
The zinger here is that if the sudo tar step of filetool.sh -r has to create any parent directories, the parent directories will be owned by root. This creates problems inside of /home.
I really don't want to backup my entire /home/bruno/.config directory, only the subdirectories that I actually want. Same for /home/bruno/.local
Now that I understand what's going on, I think that tar's behavior is really sneaky here. Almost malicious. Do you agree with patching filetool.sh as I proposed in Reply #7 to workaround this sneaky behavior inside of user's home directory? If so, it may help other users from stumbling on this. If not, no biggie because the chown statement I've added to the top of my .profile solves this for me.
-
Hi GNUser
Rich, did you try my simple experiment in Reply #11? ...
Yes I did. Here's what the /etc directory looked like:
tc@HP-G62:~/test2$ tree -ug etc
etc
|-- [tc staff ] X11
| `-- [tc staff ] xorg.conf
|-- [tc staff ] firefox
| `-- [tc staff ] policies
| `-- [tc staff ] policies.json
|-- [root staff ] group
|-- [root staff ] gshadow
|-- [root staff ] passwd
|-- [root staff ] shadow
`-- [root root ] sudoers
3 directories, 7 filesThe etc directory was root:staff.
That was the only part of my backup that contained files owned
by me. This was true for both busybox and GNU sudo tar.
... Do you agree with patching filetool.sh as I proposed in Reply #7 to workaround this sneaky behavior inside of user's home directory? ...
What purpose does the question mark serve, or is it a typo:
if grep -Eq "^/?home/$USER" /opt/.filetool.lst; then
I'm a little leery about blindly changing owner:group settings on files.
I suspect owner might be OK.
Is it possible to break something if for example a files group was
changed from snd to staff?
Maybe some of the smart kids in the room could weigh in?
-
The ? just means the leading slash can be there 0 or 1 times.
I'm not sure a blind change to $USER:staff recursively is the right thing too. I purposely make some root owned stuff in my .local directory and some of it is suid too. And I'm not running a persistent home.
-
I just got home, and ran your test in post 11. when extracted with "sudo tar -xvf mydata.tcz" the files have the proper ownership. (Not everything is root owned)
filetool.sh sets "useBusybox" so this should always be using busybox tar.
Tested in busybox 1.36,
-
Hi Paul_123
The ? just means the leading slash can be there 0 or 1 times. ...
Thank you.
-
The ? just means the leading slash can be there 0 or 1 times.
I'm not sure a blind change to $USER:staff recursively is the right thing too.
Hi Paul_123. Yes, that was my intention with the question mark.
Fair enough on the blind change being ill-advised. I'll just deal with this with a chown in ~/.profile
Thanks for your help, Rich and Paul_123. Thread may be marked as Solved.