Hi,

I have a weird problem with strip command of binutils package.
When I run this command from a shell script, I get a permission denied error.
Instead, if I run the same command for the same user from a terminal session, it works!
Moreover, I always used this script and it always worked but
I don't understand the reason for which it fails on these resources.
Any advice?

Best regards

It might help for us to see the script, at least the strip bit and surrounding lines.

The command is :
I didn't posted other code because is useless.
Anyway, I tried to run that script as root ad it worked.
Why? I don't understand the reason.
Basically, I download a tar archive from internet, extract it into a folder and
strip the executables and shared objects.
This script always worked, just for this archive it fails with permission denied error.
I tried to inspect the previous tar archives than this one,
I also saw that for those archive the owner and group are set to root, hence, that seem useless (theorically).
Why does it not work in this case as normal user ?

The most obvious answer is: because the user has no right to write that file. strip tries to modify a file, so it requires both read and write permission.
Check them.

Does your script extract to /tmp or /var/tmp?
The Linux kernel behavior changed, now root is restricted in directories with a t-bit.
https://www.claudiokuenzler.com/blog...-tmp-even-root
You can change it back to the Unix standard:
or

I am fully agree with you but like I wrote above,
if I run the same command for the same user in a terminal session, it works.
The problem only exist when it is executed from shell script
and that's very weird.

Actually, my script is not extract but the files are extracted which will be stripped instead.
fs.protected_regular is already set to zero.

Heh ... Looking up the manual page, I very-innocently used the search term: "man strip."

precious

I just added "chmod u+w $res" before strip execution and it worked but, anyway
that's is weird because:
1) The resource has already write permission.
2) If I run the same command for the same user into terminal session, it works.

Likely, when the files are extracted from tar archive, inherit the fake permissions....
Just a thought.

Mark as solved.

tar itself restores the original permissions, at least it tries. You need to read the man page for details, it may work differently for users and root.

I agree again, but if I extract tar archive and see that the permissions are correct (read, write and execution in my case) for the current user then expect it works, regardless man page reading.
When I run "chmod u+w", on the file system nothing changes occurs but i have to do that otherwise doesn't work.
According tar man page:
The umask for my user is 0022 which is 0644 like permissions.
It should works without any changes but it doesn't....

Is a special file system type involved?

"$res" is a simply resource (file/folder/symlink) extracted from tar archive.
Filesystem is Ext4 on Luks.

If it is true you did not tell us the full story. If it is a remote drive, if several hosts are involved, if <whatever>... which was not explained.
Otherwise would be nice to see the exact commands, the exact result and obviously the real environment.