Bug 10897 - DOS app invoking windows app fails
DOS app invoking windows app fails
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
All All
: P5 normal
: ---
Assigned To: Samba QA Contact
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2014-10-25 08:47 UTC by kronostm
Modified: 2014-10-27 17:32 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description kronostm 2014-10-25 08:47:07 UTC
I detected this issue after upgrading from samba 3.x to samba 4.1.6-ubuntu
I can't even say 100% sure it's a bug, but I tried to reproduce it on another machine with same samba 4.1.6 and the behavior was similar, and I found no way to fix it, so I think it might be a bug.

As far as I can tell the issue affects only Windows 7 machines, Win XP works fine and I had no win8 to test
The same setup has been working for years, until I upgraded to samba 4.1.6
What happens is that on a mapped network drive, running foxpro.exe and then from within foxpro trying to run a windows executable, an access denied message appears in foxpro and the application does not run. If I try to run a dos application from within foxpro it runs correctly. Everything is on the mapped network drive.
Same windows application runs fine if ran directly from the network drive without use of foxpro
Same setup had been working for years, it's not a matter of user rights as the issue arises for any user if trying to run from windows 7
I found nothing relevant in samba's logs nor in windows event viewer, but I admit that log level 10 generates a huge amount of data which I can't really understand.
I tried many samba parameters with no success, also tried a default smb.conf from samba4 with just the share added, like this:
   path = /path_to_share/
   public = yes
   read only = no
   case sensitive = no
   writable = yes
   printable = no
   valid users = @madmin,@mcontab
   write list = @madmin,@mcontab

Please let me know what extra information you need and I will try to provide it.
Once again, if this is not a bug but something that I am missing, I apologise.
Comment 1 kronostm 2014-10-25 13:21:39 UTC
I just tested with log level 10 two different situations:
- running from foxpro - BROWSE.EXE - windows executable
- running from foxpro - ARJ.EXE - DOS executable

As stated in my original post, ARJ.EXE completes sucessfuly while the windows executable returns an "access denied" in foxpro

every file in that folder is 777, just to be sure

Comparing the log file (damn long), I noticed this:

for ARJ.EXE I had one line like:
   fd_open: name FPD26/ARJ.EXE, flags = 00 mode = 0766, fd = 47 
*** why is it 766 instead of 777 ?
followed by: 
*user* opened file FPD26/ARJ.EXE read=Yes write=No (numopen=15)
*** why write=No ?  probably because user is not owner, but in group and somehow permissions became 766

for BROWSE.EXE I have identical lines like what I pasted above regarding ARJ, but then, after many thousands lines, the fd_open appears again:
     fd_open: name FPD26/BROWSE.EXE, flags = 00 mode = 0766, fd = 46.
     *user* opened file FPD26/BROWSE.EXE read=No write=No (numopen=14)
this time, as you can see, it gets a "read=No"
Comment 2 kronostm 2014-10-27 17:32:38 UTC
I managed to narrow it down around the option:
map system = yes
this one is needed so that windows executables can be run from within DOS executables (FOXPRO in my case), this is what this bug was all about), however activating this option renders any DOS executable unreachable (can't be run). What I actually did is starting foxpro app with "map system = no" which is default, then once everything was in memory already I changed the option to "yes", then I tried to run the windows executable from within the fox session that was already in memory and it worked. However, nothing else worked anymore as foxpro was unable to read anything else in the share (this is my guess), even though when I was trying to re-run it with "map system = yes" still in effect, I got a message (didn't write it down) about not being able to run this version of FOX, so it was somehow aware of what I am doing but couldn't find its way around.
I don't know if this makes any sense, but I guess something with the behavior of this option is the culprit here.

I tried playing with every parameter I could think about in conjunction with "map system = yes" but I was unable to find something that would still allow DOS executables to be ran while this param is set to "yes".

Still thinking it's a bug.