End of startup wizard fails with "operation not supported"

[gdevenyi]

                               Apply changes to ~/.zshrc?

(y)  Yes (recommended).

(n)  No. I know which changes to apply and will do it myself.

(r)  Restart from the beginning.
(q)  Quit and do nothing.

Choice [ynrq]: cp: preserving permissions for ‘/tmp/user/1111/.zshrc.185WPA3Hcg’: Operation not supported


--- stack trace (most recent call first) ---
/home/cic/devgab/.oh-my-zsh/custom/themes/powerlevel10k/internal/wizard.zsh:1694
/home/cic/devgab/.oh-my-zsh/custom/themes/powerlevel10k/internal/wizard.zsh:2222
/home/cic/devgab/.oh-my-zsh/custom/themes/powerlevel10k/internal/p10k.zsh:7022
/home/cic/devgab/.oh-my-zsh/custom/themes/powerlevel10k/internal/p10k.zsh:7150
zsh:1
--- end of stack trace ---

[Syphdias]

To me this sounds like an issue with your file system or user/identity provider.
Where are you running this? What operating system do you use? What file system do you use? What do you use for users? LDAP? Are you running this in a container? Are you using AppArmor or SELinux?

[gdevenyi]

This is on

• Ubuntu MATE 24.04
• NFS $HOME
• NIS
• no container
• apparmor defaults except for adding my $HOME to apparmor/homedirs

[Syphdias]

Cool, you have three things where I am not 100% sure, they are not the issue (NFS, NIS, AppArmor).

This relates to #2896 where the issue is, that cp -p does not work.
It might be due to coping between different file systems (temp <-> NFS home) or because AppArmor forbids copying permissions. NIS and NFS are probably fine. You could test by cp -p ~/somefile ~/copyofsomefile

The issue from above mentions a workaround of temporarily setting:

mkdir ~/temp
export TMPDIR=~/temp

You might want to try that.

Note on issue #2896: stickbit is almost certainly not the issue; and the fallback is just on the fork…

[romkatv]

Thanks for the analysis, @Syphdias. The past issue you've linked is very relevant.

My guess is that cp -p ~/somefile ~/copyofsomefile will succeed. It'll fail for the OP when copying between home and /tmp. The workaround should work.

[Syphdias]

Would this be an acceptable fallback quantumnic@641facd#diff-30317f6881405a55354b63eb86b43c2dcc191b04fb50b99f5436f52ca962ed12L1699-L1984?
I disagree with 2>/dev/null and using cat might be overkill but generally it might work okay.

Alternatively warning about this limitation and suggesting the workaround in theses cases might be nice as well.

[romkatv]

I cannot say off the top of my head whether it's acceptable but probably not. I never put things like -p if they aren't necessary. The workaround would likely need to be bigger -- the same purpose that -p serves would need to be served by something else.

[Syphdias]

Sorry, I meant suggesting a workaround if cp -p fails, if the fallback is not good enough. Something like:

(export TMPDIR=$(mktemp -d ~/p10ktmp.XXXXX); p10k configure; rm -r "$TMPDIR")

[Syphdias]

Did the workaround of using a different TMPDIR work for you @gdevenyi?

[gdevenyi]

Exporting TMPDIR to a path within $HOME solved the crash