Unable to get execute bit on Samba share working with Windows 7 client

I keep most of my files on an Ubuntu 14.04 box in Samba shares and access them from Windows 7 client machines. I had this all working with Ubuntu 11.10 and somehow broke this when moving to 14.04. There is an extra layer of indirection within the server via greyhole (jbod storage pooling via Samba) but it is only a plugin to Samba and does not change permissions.

Problem:

1. An EXE is saved by W7-client to Samba share.
2. Permissions look correct from command-line on server
3. W7-client cannot execute file (I can't post image due to low reputation).

"Windows cannot access \\server\Software\Internet\WinApps\Multimedia\SetupProg.exe. You do not have permissions to access \\server\Software\Internet\WinApps\Multimedia\SetupProg.exe."

Windows sees the following permissions on the EXE:

Everyone: Read
root (Unix User\root): Read & Execute, Read, Write, Special
sambashare (Unix Group\sambashare): Read, Write

I use a group "sambashare" as a common group for all users accessing via Samba shares. I have sticky bits set as seen here:

drwsrwsr-x 31 root     sambashare 12288 Apr 25 20:11 ../

So I consistently get owner=root, group=sambashare. No issues there.

Looking from the server side I see:

$ ls -l /mnt/lsi11/shares/Software/Internet/WinApps/Multimedia
lrwxrwxrwx  1 root sambashare    69 Apr 25 16:14 SetupProg.exe -> /mnt/lsi4/gh/Software/Internet/WinApps/Multimedia/SetupProg.exe

$ ls -l /mnt/lsi4/gh/Software/Internet/WinApps/Multimedia
-rwxrw-r--  1 root sambashare 11800240 Apr 25 15:23 SetupProg.exe

The group execute bit is not being set.

Looking at the smb.conf for the share I have (including items from @Terrance):

[Global]
   wide links = yes
   unix extensions = no
   workgroup = WORKGROUP
   server string = %h server (Samba, Ubuntu)
   wins support = yes
   dns proxy = no
   name resolve order = lmhosts host wins bcast
   log file = /var/log/samba/log.%m
   max log size = 5000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   security = user
   encrypt passwords = true
   server role = standalone server
   passdb backend = tdbsam
   obey pam restrictions = no
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   printing = bsd
   printcap name = /dev/null
   usershare allow guests = yes

   follow symlinks = yes
   ntlm auth = no
   lanman auth = no
   client ntlmv2 auth = yes
   usershare owner only = no

[Software]
   comment = Software files
   browsable = yes
   path = /mnt/lsi11/shares/Software
   read only = no
   valid users = user1 user2
   guest ok = no
   inherit owner = yes
   inherit permissions = yes
   dfree command = /usr/bin/greyhole-dfree
   vfs objects = greyhole

I am able to manually set the execute bit from Linux and fix existing files. Any suggestions where to go poking would be helpful.

Solution 1:

In the [global] section of your /etc/samba/smb.conf add the following lines:

[global]

usershare owner only = false
unix extensions = no
follow symlinks = yes
wide links = yes

ntlm auth = no
lanman auth = no
client ntlmv2 auth = yes

Also, check the way the NTFS partitions are mounted in the /etc/fstab file. I had to add default 0 0 to the end of my NTFS mounts, that way it opened up all the permissions for the files to be accessible. I put an example of how my mounts are.

UUID=0A485DBF485DAA69 /media/500GB ntfs default 0 0
UUID=6AAA4323AA42EB61 /media/SGUSB ntfs default 0 0

Hopefully this helps.

EDIT: I totally forgot this one was still open, and I missed something. As it turns out, this is a bug, and can be remedied by the following lines:

Workaround:

-- /etc/samba/local.conf
[global]
  acl allow execute always = True
--

Information can be found in the bug report here.