PowerShell 7.5 still doesn't ship with the execute flag set

Hello,

I have moved it to a new thread.

Could you send us some logs or a way to reproduce this issue?

Best regards,

We run the Linux ZIP method on Rocky 9.8. Each time we upgrade, we have to run sudo chmod +x /opt/psuniversal/Hosts/7.5/PowershellUniversal.Host. Here is our upgrade script if you would like to take a look at it:

# These are used to derive the download URL
PSU_VERSION="2026.3.3.0" # Change this to the current version
PSU_ARCH="x64" # Change this to your desired architecture
PSU_FILE="Devolutions.PowerShellUniversal.linux-${PSU_ARCH}.${PSU_VERSION}.zip"
#PSU_URL="https://powershelluniversal.devolutions.net/download/psu/previous/${PSU_VERSION}/${PSU_FILE}"
PSU_URL="https://cdn.devolutions.net/download/${PSU_FILE}"

# These are used for installing PowerShell Universal
# If you'd like to use a different path, change this
PSU_PATH="/opt/psuniversal"
PSU_EXEC="${PSU_PATH}/Universal.Server"

# These are for installing it as a service
PSU_SERVICE="psuniversal"
PSU_USER="psuniversal"

BACKUP_DATE=$(date +"%Y%m%d_%H%M%S")
BACKUP_FILE="backup-${BACKUP_DATE}.tar.gz"
BACKUP_FILE_PATH="/home/psuniversal/${BACKUP_FILE}"
BACKUP_SOURCE="/home/psuniversal/.PowerShellUniversal"

echo "Stopping PSU"
sudo systemctl stop $PSU_SERVICE

echo "Making backup"
sudo tar -czf $BACKUP_FILE_PATH -C $BACKUP_SOURCE .

echo "Deleting existing installation folder"
sudo rm -rf $PSU_PATH

echo "Creating $PSU_PATH and granting access to $USER"
sudo mkdir $PSU_PATH
sudo setfacl -m "u:${USER}:rwx" $PSU_PATH

echo "Creating user $PSU_USER and making it the owner of $PSU_PATH"
sudo chown $PSU_USER -R $PSU_PATH

echo "Downloading PowerShell Universal $PSU_VERSION ($PSU_ARCH)"
wget -q $PSU_URL -O $PSU_FILE

echo "Extracting $PSU_FILE to $PSU_PATH"
unzip -o -qq $PSU_FILE -d $PSU_PATH

echo "Make $PSU_EXEC executable"
sudo chmod +x $PSU_EXEC

echo "Changing port to 50000"
sudo sed -i 's/*:5000"/*:50000"/' /opt/psuniversal/appsettings.json
sudo sed -i 's/*:5000"/*:50000"/' /opt/psuniversal/appsettings.linux.json

echo "Starting PSU"
sudo systemctl start $PSU_SERVICE
sudo systemctl status $PSU_SERVICE --no-pager

If you need our service file (/etc/systemd/system/psuniversal.service), here it is:

[Unit]
Description=PowerShell Universal
[Service]
ExecStart=/opt/psuniversal/Universal.Server
SyslogIdentifier=psuniversal
User=psuniversal
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target

I should also add that we have apps that utilize environments that utilize that instance of PowerShell, and they will fail to start unless we set the execution flag.

Hello Andrew,

Thank you for the details and the upgrade script, which made this quick to confirm.

You are right, and it is not specific to your setup.

The ZIP does not store any Unix file permissions, so every file extracts without the execute bit.

That includes Hosts/7.5/PowerShellUniversal.Host, so any environment that uses the bundled PowerShell host fails to start, along with the apps that run in it.

Your script deletes and re-extracts the folder on each upgrade, so the bit is lost every time, which matches what you see.

Our documented Linux steps and the Install-PSUServer cmdlet only set the execute bit on Universal.Server, which is why the other binaries are missed.

I have reported this to the product team so the package ships with the right permissions.

Until then, you can replace the chmod line in your upgrade script with the one below, right after the unzip step.

(cd "$PSU_PATH" && sudo chmod +x \

Universal.Server PowerShellUniversal.Host psu PSUAgent \

pwsh multi-pwsh createdump AspNetCoreRateLimit \

PowerShellUniversal.Extensibility \

PowerShellUniversal.Plugin.OpenTelemetry PowerShellUniversal.Plugin.YARP \

Hosts/7.5/PowerShellUniversal.Host Hosts/7.5/pwsh Hosts/7.5/createdump)

It covers Universal.Server, the bundled PowerShell host, and every other executable we found in the 2026.3.3.0 package.

With it in place, your apps should start right after the next upgrade, with no manual step.

I will update this thread as soon as I have a fix version to share.

Best regards,

Hello,

Thank you for your patience while our team looked into the issue you reported.

I'm happy to let you know that the latest version of PowerShell Universal (2026.3.4) includes a fix for this problem. You can download it from our website here:

https://devolutions.net/download-center/#psu

Once you have installed the update, could you please test it in your environment and confirm that everything now works as expected? If the issue persists or if you notice anything unusual related to the same original problem, just reply to this message with a few details, and we will be glad to look into it further.

Thank you for your collaboration.

Best regards,