Pyinstaller: PyInstaller 3.6 breaks WINE compatibility when using onefile

[wmtorode]

PyInstaller 3.6 has broken onefile compatibility with WINE.

onefile applications built with pyinstaller 3.6 results in applications that run fine under windows, but trying to run the application in WINE reports a "interanl error cannot create temporary directory" error. By the looks of it a temp directory is created but the directory has no write access:

d--------- 2 nikita nikita 4096 Jan 14 00:39 _MEI82

building the same application with pyinstaller 3.5 and it works without issue

[pinobatch]

I had to upgrade from Wine 3.6 to Wine 5 just to install Python because Python 3.8's own installer was creating no-permissions directories. After that, here are some steps to reproduce...

I'm using PyInstaller 3.6 in Python 3.8.1 for Windows in Wine 5.0 (from WineHQ repo) in Ubuntu 18.04 LTS in order to cross-compile a Python program (wav2brr.py from lorom-template) to a Windows executable.

First I removed outdated Wine 3.6 from Canonical's repo and installed Wine from WineHQ's repo to replace it, then installed Python and PyInstaller.

sudo dpkg --add-architecture i386
sudo apt remove libwine-development libwine-development:i386
wget -qO - https://dl.winehq.org/wine-builds/winehq.key | sudo apt-key add -
sudo apt-add-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ bionic main'
sudo add-apt-repository ppa:cybermax-dexter/sdl2-backport
sudo apt update
sudo apt install --install-recommends winehq-stable
wget https://www.python.org/ftp/python/3.8.1/python-3.8.1-amd64.exe
wine ./python-3.8.1-amd64.exe /passive
wine py -m pip install --upgrade pip
wine py -m pip install pyinstaller

With PyInstaller installed, I proceeded to build a one-file executable:

$ wget https://github.com/pinobatch/lorom-template/raw/master/tools/wav2brr.py
$ wine \path\to\pyinstaller.exe --onefile -d bootloader wav2brr.py
$ wine dist/wav2brr.exe
[44] PyInstaller Bootloader 3.x
[44] LOADER: executable is Z:\home\pino\develop\pyinstallerwin\dist\wav2brr.exe
[44] LOADER: homepath is Z:\home\pino\develop\pyinstallerwin\dist
[44] LOADER: _MEIPASS2 is NULL
[44] LOADER: archivename is Z:\home\pino\develop\pyinstallerwin\dist\wav2brr.exe
[44] LOADER: Extracting binaries
[44] INTERNAL ERROR: cannot create temporary directory!
[44] LOADER: temppath is 
[44] LOADER: Error extracting binaries
002b:fixme:ver:GetCurrentPackageId (0x22faa0 (nil)): stub

Only a space is printed after temppath is. What path does this mean it is searching? Advanced Topics doesn't seem to explain how temppath is chosen.

(One-folder executables appear to work correctly though.)

[Legorooj]

temppath is the system temporary directory, eg /tmp, /var/tmp etc.

[Legorooj]

This appears to be permission related. Can you run as Sudo?

[pinobatch]

Wine FAQ 6.2: Should I run Wine as root?

⚠️ NEVER run Wine as root! Doing so gives Windows programs (and viruses) full access to your computer and every piece of media attached to it. Running with sudo also has these same risks but with the added bonus of breaking the permissions on your ~/.wine folder in the process. If you have run Wine with sudo you need to fix the permission errors as described in the next question, and then run winecfg to set Wine up again. You should always run Wine as the normal user you use to login.

For Linux systems, all ideas that Wine needs root can be solved through Posix Capabilities or Posix File Capabilities or correcting other security settings.

As far as Windows programs are concerned, you are running with administrator privileges. If an application complains about a lack of administrator privileges, file a bug; running Wine as root probably won't help.

How would I go about setting up a container to protect the rest of my system from the damage that sudo wine can cause? How would I debug pyinstaller to see what exact path it is trying to construct for the temporary directory and which error code Wine is returning?

[Legorooj]

Umm. If you have enough ram a VM running Ubuntu might work... Replicate the Env etc. Also py3.8 isn't supported yet, and likely won't be until PyInstaller 4.1 (2 releases away).

[pinobatch]

Does it support Python 3.7.6? Because I uninstalled Python 3.8.1, installed Python 3.7.6, tried again, and got the same error:

[43] PyInstaller Bootloader 3.x
[43] LOADER: executable is Z:\home\pino\develop\pyinstallerwin\dist\hw.exe
[43] LOADER: homepath is Z:\home\pino\develop\pyinstallerwin\dist
[43] LOADER: _MEIPASS2 is NULL
[43] LOADER: archivename is Z:\home\pino\develop\pyinstallerwin\dist\hw.exe
[43] LOADER: Extracting binaries
[43] INTERNAL ERROR: cannot create temporary directory!
[43] LOADER: temppath is 
[43] LOADER: Error extracting binaries
002c:fixme:ver:GetCurrentPackageId (0x22faa0 (nil)): stub

sudo wine dist/wav2brr.exe produced the following error:

/home/pino/.wine is not owned by you

This leaves setting up a virtual machine. This being my first virtual machine in my life, it may take a day for me to get back to you.

[Legorooj]

There are guides online. I'd recommend Virtual Box as your manager. Yes 3.7 is supported. Can you check the permissions on your temp folder? touch might work.

[pinobatch]

Both temp folders that I know of are world-writable:

$ ls -l /tmp /var/tmp
drwxrwxrwt 22 root root 270336 Feb 20 20:59 /tmp
drwxrwxrwt  9 root root   4096 Feb 20 20:44 /var/tmp
$ touch /tmp/okay1 /var/tmp/okay1
$ ls -l /tmp/okay1 /var/tmp/okay1
-rw-rw-r-- 1 pino pino 0 Feb 20 19:59 /tmp/okay1
-rw-rw-r-- 1 pino pino 0 Feb 20 19:59 /var/tmp/okay1

Everything below is in a guest

Once I had established ssh -X connectivity to a freshly installed copy of Xubuntu 18.04 in VirtualBox, I ran these commands:

sudo dpkg --add-architecture i386
wget -qO - https://dl.winehq.org/wine-builds/winehq.key | sudo apt-key add -
sudo apt-add-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ bionic main'
sudo add-apt-repository ppa:cybermax-dexter/sdl2-backport
sudo apt update
sudo apt upgrade
sudo apt install --install-recommends winehq-stable
sudo -i
xauth merge /home/pino/.Xauthority
wget https://www.python.org/ftp/python/3.7.6/python-3.7.6-amd64.exe
wine ./python-3.7.6-amd64.exe /passive
wine py -m pip install --upgrade pip
wine py -m pip install pyinstaller
echo 'print("hello")' > hw.py
wine 'C:\users\root\Local Settings\Application Data\Programs\Python\Python37\Scripts\pyinstaller.exe' hw.py
wine dist/hw/hw.exe
rm -r dist
wine 'C:\users\root\Local Settings\Application Data\Programs\Python\Python37\Scripts\pyinstaller.exe'  --onefile -d bootloader hw.py
wine dist/hw.exe

This actually worked:

[42] PyInstaller Bootloader 3.x
[42] LOADER: executable is Z:\root\dist\hw.exe
[42] LOADER: homepath is Z:\root\dist
[42] LOADER: _MEIPASS2 is NULL
[42] LOADER: archivename is Z:\root\dist\hw.exe
[42] LOADER: Extracting binaries
[42] LOADER: Executing self as child
[42] LOADER: set _MEIPASS2 to C:\users\root\Temp\_MEI422
[42] LOADER: Setting up to run child
[42] LOADER: Creating child process
[42] LOADER: Waiting for child process to finish...
[44] PyInstaller Bootloader 3.x
[44] LOADER: executable is Z:\root\dist\hw.exe
[44] LOADER: homepath is Z:\root\dist
[44] LOADER: _MEIPASS2 is C:\users\root\Temp\_MEI422
[44] LOADER: archivename is Z:\root\dist\hw.exe
[44] LOADER: SetDllDirectory(C:\users\root\Temp\_MEI422)
[44] LOADER: Already in the child - running user's code.
[44] LOADER: manifestpath: C:\users\root\Temp\_MEI422\hw.exe.manifest
[44] LOADER: Activation context created
[44] LOADER: Activation context activated
[44] LOADER: ucrtbase.dll is exists: C:\users\root\Temp\_MEI422\ucrtbase.dll
[44] LOADER: Python library: C:\users\root\Temp\_MEI422\python37.dll
[44] LOADER: Loaded functions from Python library.
[44] LOADER: Manipulating environment (sys.path, sys.prefix)
[44] LOADER: sys.prefix is C:\users\root\Temp\_MEI422
[44] LOADER: Pre-init sys.path is C:\users\root\Temp\_MEI422\base_library.zip;C:\users\root\Temp\_MEI422
[44] LOADER: Setting runtime options
[44] LOADER: Bootloader option: pyi-windows-manifest-filename hw.exe.manifest
[44] LOADER: Initializing python
[44] LOADER: Overriding Python's sys.path
[44] LOADER: Post-init sys.path is C:\users\root\Temp\_MEI422\base_library.zip;C:\users\root\Temp\_MEI422
[44] LOADER: Setting sys.argv
[44] LOADER: setting sys._MEIPASS
[44] LOADER: importing modules from CArchive
[44] LOADER: extracted struct
[44] LOADER: callfunction returned...
[44] LOADER: extracted pyimod01_os_path
[44] LOADER: callfunction returned...
[44] LOADER: extracted pyimod02_archive
[44] LOADER: callfunction returned...
[44] LOADER: extracted pyimod03_importers
[44] LOADER: callfunction returned...
[44] LOADER: Installing PYZ archive with Python modules.
[44] LOADER: PYZ archive: PYZ-00.pyz
[44] LOADER: Running pyiboot01_bootstrap.py
[44] LOADER: Running hw.py
hello
[44] LOADER: OK.
[44] LOADER: Cleaning up Python interpreter.
002d:fixme:ver:GetCurrentPackageId (0x22faa0 (nil)): stub
[42] LOADER: Back to parent (RC: 0)
[42] LOADER: Doing cleanup
[42] LOADER: Freeing archive status for Z:\root\dist\hw.exe
002b:fixme:ver:GetCurrentPackageId (0x22faa0 (nil)): stub

Then I repeated this under a second wineprefix owned by an ordinary user in the same VM:

chown pino python-3.7.6-amd64.exe
mv python-3.7.6-amd64.exe /home/pino
exit
wine ./python-3.7.6-amd64.exe /passive
wine py -m pip install --upgrade pip
wine py -m pip install pyinstaller
echo 'print("hello")' > hw.py
wine 'C:\users\pino\Local Settings\Application Data\Programs\Python\Python37\Scripts\pyinstaller.exe' hw.py
wine dist/hw/hw.exe
rm -r dist
wine 'C:\users\pino\Local Settings\Application Data\Programs\Python\Python37\Scripts\pyinstaller.exe'  --onefile -d bootloader hw.py
wine dist/hw.exe

Same error as before:

[43] PyInstaller Bootloader 3.x
[43] LOADER: executable is Z:\home\pino\develop\pyinstallerwin\dist\hw.exe
[43] LOADER: homepath is Z:\home\pino\develop\pyinstallerwin\dist
[43] LOADER: _MEIPASS2 is NULL
[43] LOADER: archivename is Z:\home\pino\develop\pyinstallerwin\dist\hw.exe
[43] LOADER: Extracting binaries
[43] INTERNAL ERROR: cannot create temporary directory!
[43] LOADER: temppath is 
[43] LOADER: Error extracting binaries
002c:fixme:ver:GetCurrentPackageId (0x22faa0 (nil)): stub

What further steps should I take to troubleshoot the permission problem in the guest?

[Legorooj]

Hmm. We need to figure out the actual temp directory... What does python -c "import tempfile; print(tempfile.gettempdir())" output?

[pinobatch]

It's resolving to a directory within my wineprefix:

$ wine cmd
Microsoft Windows 6.1.7601

Z:\home\pino>py -c "import tempfile; print(tempfile.gettempdir())"
002b:fixme:sync:NtQueryInformationJobObject stub: 0x58 9 0x32f410 112 0x32f40c
002d:fixme:msvcrt:_configure_wide_argv (1) stub
002d:fixme:msvcrt:_initialize_wide_environment stub
C:\users\pino\Temp
002b:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFA, 0032F350

Z:\home\pino>echo %Temp%
C:\users\pino\Temp

Z:\home\pino>echo %Tmp%
C:\users\pino\Temp

Z:\home\pino>exit
$ winepath -u C:\\users\\pino\\Temp
/home/pino/.wine/dosdevices/c:/users/pino/Temp

Is there a chat server where we could do this troubleshooting in real time, and then I later summarize to this issue?

[Legorooj]

None I know of. What are the permissions on the actual temppath? The Linux one. Every folder in it, starting from .wine to Temp.

[pinobatch]

$ ls -ld ~/.wine/ ~/.wine/dosdevices/ ~/.wine/dosdevices/c: ~/.wine/drive_c/ ~/.wine/drive_c/users/ ~/.wine/drive_c/users/pino/ ~/.wine/drive_c/users/pino/Temp/
drwxrwxr-x  4 pino pino 4096 Feb 21 15:19 /home/pino/.wine/
drwxrwxr-x  2 pino pino 4096 Feb 21 15:19 /home/pino/.wine/dosdevices/
lrwxrwxrwx  1 pino pino   10 Jun 10  2018 /home/pino/.wine/dosdevices/c: -> ../drive_c
drwxrwxr-x  7 pino pino 4096 Jun 10  2018 /home/pino/.wine/drive_c/
drwxrwxr-x  4 pino pino 4096 Jun 10  2018 /home/pino/.wine/drive_c/users/
drwxrwxr-x 17 pino pino 4096 Feb 16 19:31 /home/pino/.wine/drive_c/users/pino/
drwxrwxr-x 27 pino pino 4096 Feb 21 09:02 /home/pino/.wine/drive_c/users/pino/Temp/

However the folders that get created inside have no permissions.

$ ls -l /home/pino/.wine/drive_c/users/pino/Temp/
total 4444
d--------- 2 pino pino   4096 Feb 16 21:24  _MEI4210
d--------- 2 pino pino   4096 Feb 16 21:24  _MEI4211
d--------- 2 pino pino   4096 Feb 16 20:38  _MEI422
d--------- 2 pino pino   4096 Feb 16 20:38  _MEI423
d--------- 2 pino pino   4096 Feb 16 20:38  _MEI424
d--------- 2 pino pino   4096 Feb 16 20:38  _MEI425
d--------- 2 pino pino   4096 Feb 16 20:38  _MEI426
d--------- 2 pino pino   4096 Feb 16 21:24  _MEI427
d--------- 2 pino pino   4096 Feb 16 21:24  _MEI428
d--------- 2 pino pino   4096 Feb 16 21:24  _MEI429
d--------- 2 pino pino   4096 Feb 20 21:55  _MEI4310
d--------- 2 pino pino   4096 Feb 20 21:55  _MEI4311
d--------- 2 pino pino   4096 Feb 20 19:26  _MEI432
d--------- 2 pino pino   4096 Feb 20 19:26  _MEI433
d--------- 2 pino pino   4096 Feb 20 19:26  _MEI434
d--------- 2 pino pino   4096 Feb 20 19:26  _MEI435
d--------- 2 pino pino   4096 Feb 20 19:26  _MEI436
d--------- 2 pino pino   4096 Feb 20 21:55  _MEI437
d--------- 2 pino pino   4096 Feb 20 21:55  _MEI438
d--------- 2 pino pino   4096 Feb 20 21:55  _MEI439
d--------- 2 pino pino   4096 Feb 16 21:03  _MEI442
d--------- 2 pino pino   4096 Feb 16 21:03  _MEI443
d--------- 2 pino pino   4096 Feb 16 21:03  _MEI444
d--------- 2 pino pino   4096 Feb 16 21:03  _MEI445
d--------- 2 pino pino   4096 Feb 16 21:03  _MEI446

[other unrelated files snipped]

Is there a reason why the bootloader prints [44] LOADER: temppath is without anything else on the line after the word is?

[Legorooj]

The line above temppath is says INTERNAL ERROR: cannot create temporary directory!. Hmm this is really confusing. Is the output different if you use the dosdevices path instead? Sometimes forwarding things Cann mess with permissions - on windows anyway.

[pinobatch]

What do you mean by "use the dosdevices path"? Where in particular would I "use" it?

[Legorooj]

@pinobatch run the following command and check that the output is the same as the similar one above.

ls -ld ~/.wine/ ~/.wine/dosdevices/ ~/.wine/dosdevices/c: ~/.wine/dosdevices/c:/ ~/.wine/dosdevices/c:/users/ ~/.wine/dosdevices/c:/users/pino/ ~/.wine/dosdevices/c:/users/pino/Temp/

[pinobatch]

All are world-readable, group-writable, and world-traversable, yet the _MEI* directories created inside are permissionless:

$ ls -ld ~/.wine/ ~/.wine/dosdevices/ ~/.wine/dosdevices/c: ~/.wine/dosdevices/c:/ ~/.wine/dosdevices/c:/users/ ~/.wine/dosdevices/c:/users/pino/ ~/.wine/dosdevices/c:/users/pino/Temp/
drwxrwxr-x  4 pino pino 4096 Feb 22 17:26 /home/pino/.wine/
drwxrwxr-x  2 pino pino 4096 Feb 22 17:25 /home/pino/.wine/dosdevices/
lrwxrwxrwx  1 pino pino   10 Jun 10  2018 /home/pino/.wine/dosdevices/c: -> ../drive_c
drwxrwxr-x  7 pino pino 4096 Jun 10  2018 /home/pino/.wine/dosdevices/c:/
drwxrwxr-x  4 pino pino 4096 Jun 10  2018 /home/pino/.wine/dosdevices/c:/users/
drwxrwxr-x 17 pino pino 4096 Feb 16 19:31 /home/pino/.wine/dosdevices/c:/users/pino/
drwxrwxr-x 27 pino pino 4096 Feb 21 09:02 /home/pino/.wine/dosdevices/c:/users/pino/Temp/
$ ls -ld ~/.wine/dosdevices/c:/users/pino/Temp/_MEI* | head -n5
d--------- 2 pino pino 4096 Feb 16 21:24 /home/pino/.wine/dosdevices/c:/users/pino/Temp/_MEI4210
d--------- 2 pino pino 4096 Feb 16 21:24 /home/pino/.wine/dosdevices/c:/users/pino/Temp/_MEI4211
d--------- 2 pino pino 4096 Feb 16 20:38 /home/pino/.wine/dosdevices/c:/users/pino/Temp/_MEI422
d--------- 2 pino pino 4096 Feb 16 20:38 /home/pino/.wine/dosdevices/c:/users/pino/Temp/_MEI423
d--------- 2 pino pino 4096 Feb 16 20:38 /home/pino/.wine/dosdevices/c:/users/pino/Temp/_MEI424

[Legorooj]

Hmm. That is odd, but probably not related - the error is "can't create temp dir". I'm going to have to say that I've exhausted all of my Linux knowledge (which for a windows user is pretty good) and hand this one to @htgoebel, our in house Linux guru.

[yanaytevet]

I'm experiencing the same issues. Have you, by any chance, reached a solution?

[Legorooj]

We need @htgoebel for this. I'm afraid that unless @wmtorode or @pinobatch have solved this in the meantime... I'm not a Linux guru.

[htgoebel]

• In deed running a program as root, just to work-around permission issues is a bad idea. In the best case you are hiding permission problems, in the worst case you are compromising your system.
• The temppath is choosen in pyi_utils.c::pyi_get_temp_path(), for windows %TMP% is take as the base.
• The curious directory permissions are most probably is caused by security-fix 42a67148b3bdf9211fda8499fdc5b63acdd7e6cc. To validate this assumption, you might want to revert this change, rebuild the bootloader (for windows) and tr again. If this is the cause, I assume this is a limitation (or bug) of wine.

[Cheaterman]

Yeah, I was running my stuff as root (as a workaround - it's stuff I programmed myself anyway), but was looking for a better way. Seeing the code of the commit you mentioned made me think it was all happening at FS-level and not technically wine's fault, so here's what I did (spoiler alert - it works):

cd /tmp
dd if=/dev/zero of=ntfs.file bs=1M count=500
mkfs.ntfs -F ntfs.file
mkdir ntfs_mount
export WINEPREFIX='/tmp/ntfs_mount/wine64prefix' WINEARCH='win64'
sudo mount -o uid=$USER ntfs.file ntfs_mount/
wineboot -i
wine my_app.exe

So, yeah. Still looks like a workaround, but I guess that's the best we're going to get, unless (until?) someone can amend the previously mentioned commit while making sure it's still safe, or Wine fixes UNIX FS permissions in a way that's closer to what Windows programs/users would expect.

[allenyllee]

I have the same problem, and the generated exe file also can not run under Windows. So I think @Cheaterman's workround isn't a portable solution.

Just downgrade to pyinstaller 3.5 anything works fine, no matter on Wine or on Windows.

[Cheaterman]

@allenyllee I'm surprised your exe doesn't work on Windows. Are you sure there's no other issue? My workaround does nothing to the exe.

[Legorooj]

@htgoebel could this be related to the security issue on windows? There's already been repercussions for Linux, so wine might have been affected.

[allenyllee]

@Cheaterman Ya...I'm sure. The same code build by pyinstaller 3.5 and 3.6, the former works on windows, but the latter doesn't. When I execute the latter, the cursor just spinning and nothing happen, it tested on windows 10.

[imyhxy]

• In deed running a program as root, just to work-around permission issues is a bad idea. In the best case you are hiding permission problems, in the worst case you are compromising your system.
• The temppath is choosen in pyi_utils.c::pyi_get_temp_path(), for windows %TMP% is take as the base.
• The curious directory permissions are most probably is caused by security-fix 42a6714. To validate this assumption, you might want to revert this change, rebuild the bootloader (for windows) and tr again. If this is the cause, I assume this is a limitation (or bug) of wine.

My pyinstaller already is 4.0, still encounter this problem. Would you tell me the validation details? Because I'm not sure how to deal with it.

[htgoebel]

Nobody cared to follow my recommendations from https://github.com/pyinstaller/pyinstaller/issues/4628#issuecomment-632025449. so there is no reason for me to pen another minute on this issue until one did.

[Cheaterman]

Agreed. Besides no news is good news I suppose. Everything works fine for me on Windows and I made a wrapper for my workaround on 'nux... More info needed from people still experiencing issues.

[pinobatch]

Can one rebuild the bootloader for Windows using a cross-compiler on Linux? Or does rebuilding the bootloader for Windows require a Windows license?

[Legorooj]

@pinobatch the easiest method would be the Vagrantfile we provide. We can't cross-compile from Linux>Windows yet I think. However I'm in the process of writing some Dockerfiles for bootloader compilation, so I'll tag you when those are done.

[Legorooj]

Oh apparently you can't run Windows containers on Linux. I suggest a VM as the easiest way to build the bootloader yourself while running Linux.

[pinobatch]

Then I guess I might have to put this issue on hold until someone following this issue can raise the resources for a machine strong enough to run a Windows VM and for a Windows license to run in the VM.

[Legorooj]

@pinobatch you can get free Windows VM images from Microsoft designed for developers. I can also recompile the bootloaders for you if you want. Also, you don't need huge resources to run a Windows VM - I can run 5 instances of Windows (excluding the host) on my machine (16GB ram, "no" gpu, and an Intel i7).

[schlomo]

I have this problem also in combination with https://github.com/toilal/docker-pyinstaller and https://github.com/cdrx/docker-pyinstaller, it shows like this:

VCRUNTIME140.dll could not be extracted!
fopen: Permission denied

when running a Python program created by pyinstaller version 3.6 or 4.0. The Windows temp directory looks like this:

d--------- 2 19687 4724 4096 Oct  1 17:01 _MEI962

The resulting EXE actually works on Windows so that I also believe that this is a wine bug.

The main problem (at least for me) is that now I can build something but I cannot test it.

/CC @toila @cdrx

@htgoebel rebuilding pyinstaller without your security fix is currently beyond my abilities, if you give me a patched bootloader to check I'll happily do so.

[schlomo]

I created a little demo from a simple print("Hello World") Python script to demonstrate the issue.
demo.zip

Retesting this with Wine 5.18 (freshly found in development channel), the error changes to

INTERNAL ERROR: cannot create temporary directory!

[schlomo]

For reference, this bug is already reported with Wine: https://bugs.winehq.org/show_bug.cgi?id=49334

[rokm]

This is a problem on wine side, as it does not implement sufficient support for security descriptor that pyinstaller passes to CreateDirectoryW. (This was introduced by security fix 42a6714, so I don't think it's feasible to revert that in the long run).

Specifically, during the file/directory creation in wine server, security descriptor is translated into posix mode in sd_to_mode(). Current implementation supports only limited range of SIDs; it fails to recognize SID S-1-3-4, and the corresponding permissions request is quietly dropped. Therefore, the returned mode is 0, and the resulting directory is effectively created without any permissions.

I'm not really familiar with Windows permissions model nor wine's handling of it, but a naive solution may be to map S-1-3-4 (and S-1-3-0, for that matter) to the existing user-only case. I'm attaching proof-of-concept patch for reference: wineserver-file-s134.txt

Ideally, this needs to be resolved in wine - but if we wanted to work around the issue on our side, we need to find an alternative for tightening permissions on the created directory that does not involve using SIDs S-1-3-4 or S-1-3-0. Judging by the wine code, maybe using the current user id might do the trick?

[schlomo]

While waiting for a fix I stopped to use --onefile which also serves as a workaround. This has the added benefit of significantly improved startup times (1-2 secs instead of 10-12 secs).

[Legorooj]

@schlomo startup slowdowns are because when running onefile PyInstaller has to decompress and write the entire contents to the disk in a tempfolder. That isn't needed when running onedir.

[wmtorode]

many thanks for looking into a fix for this @rokm. also realize that its way late but @Legorooj my only work around to date has been to stay on pyinstaller 3.5. which thankfully hasn't held me back (it will shortly when I look to move to pyside6 though).

[Legorooj]

This fix should make it into the next release. Thanks for reporting this and being helpful!