4

I'm trying to get my linux smb/cifs client recognize the executable bits that are set on some files on a share on a linux smb server.

Here is our setup:

  1. Linux server exporting some directories via smb to clients
  2. Many windows clients accessing the shared directories
  3. Some linux clients accessing the shares

We've got some shell scripts on the shares that have the executable permission bit set on the linux server. We ssh into it and can execute them without problems.

Thanks to samba's map options, we can export the unix executable bits as archive, system and hidden permissions via the smb protocol, which works.

Now to close the loop, I need to find a way to map those archive, system and hidden bits back to the ugo executable bits on my linux clients. I didn't find a setting for that in the mount.cifs man page, but maybe it's possible somehow else?

Simply switching to NFS is something I'd like to avoid, because we have many windows clients that also use the shares. Administrating NFS would be additional work.

cweiske
  • 781
  • 1
  • 13
  • 36
  • I know it doesn't answer the question, but why not offer NFS for the Linux clients? Far easier than dealing with the fiddly Samba options and easier to administer. – Magellan Jan 16 '12 at 19:45
  • Not being snarky, but you're putting in more work fiddling with Samba than I ever did with NFS. NFS is pretty much fire & forget unless you're using NFS4, and then it's slightly more involved. And I've always found that it's easier to automate and centrally manage NFS settings than it is to automate Samba. – Magellan Jan 16 '12 at 21:38

2 Answers2

1

I'm not exactly sure from your question what is being shared from where, but my work's Samba share may be a similar situation. I've got Samba users work, chris, and wendy.

We've got a Debian server with a 4TB raid. I've got it set up so there is a general "work" username/password we all know. The raid's permissions work well for the Windows people, but I recall having to go clean up write permissions (via changing ownership) so that Windows users could edit my Linux login's work.

See my answer here: Linux user cannot read or edit outside their home directory where I talk about using the sticky bits for owner and group permissions.

Here's my raid's perms:

/raid$ ls -alh
total 33M
drwxrwsr-x.  46 work     users 4.0K Jan  7 18:33 .
drwxr-xr-x   24 root     root  4.0K Jan  4 16:13 ..
-rwxr--r--    1 wendy    users  12K Dec 31 16:57 boc.pfl
drwxrwsr-x.   7 work     users 4.0K Aug 15  2009 catalog
drwx--S--T.  43 chris    users  12K Jan  5 16:53 chris
drwxrwsr-x.   6 work     users 4.0K Dec 31 16:32 dealers
drwxrwsr-x    3 work     users 4.0K Nov  5 17:51 Distributors
drwxrwsr-x.  22 work     users 4.0K Dec 29 16:58 docs
drwx--S--T.   9 wendy    users 4.0K Jan  3 18:40 wendy
drwx------   17 work     users 4.0K Sep  8  2011 work

And I think I see what I need to research to answer my own Linux vs Windows user, the S on directories. This will have to get looked at the next time I can get away from Windows and can turn on my linux desktop again.

If you snoop around my SU or SO profiles, I'm pretty sure I've talked about all this more...

Community
  • 1
Krista K
  • 519
  • 7
  • 20
0

Why don't you just create two different configuration sections in smb.conf? One for the Windows clieants as it already is, and one for the linux clients that omits the map x = yes lines.

klugerama
  • 103
  • 3