Hello, 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: [share] 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.
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"
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.
your old applications might not work properly anymore after the move from smb1 to smb2. I'm closing this bug as there is really no information here indicating a samba bug. You might consult a company from https://www.samba.org/samba/support/globalsupport.html if this is still an issue for you.