Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm having some serious permission issues with Mac client machines (OS X Snow Leopard) connected to a UNIX server (running CentOS) through Samba. No matter which permissions I set for a file on the server, the Mac ignores them and changes the permissions back to 766.

My goal is to be able to lock a file (744) from other users when its in use or open on a client machine. Other clients should be able to read the file during this time, but not be able to write to it. I found a thread that describes my problem almost exactly suggesting to use the "unix extensions = off" parameter in the global section of the smb.conf file, but to no avail. The parameter is rejected by the "testparm" command on the the version of Samba I am running (3.4); The compiling issue is resolved by changing the parameter to "unix extensions = no" but still fails to resolve the issue.

The same issue arises when I attempt to use AFP.

I'm really unsure of where to turn next, does anyone have any suggestions or information I can utilize to solve this problem?

Thanks!

share|improve this question
add comment

3 Answers

Sorry this doesn't help the OP, but I can confirm that

unix extensions = no

worked for me. I have Macs running Snow Leopard connecting to Linux (lenny/sid) server with Samba 3.2.3. I am posting this so people will still try that. Much like others, before I put the unix extensions = no line in, the force create mode was being ignored.

share|improve this answer
add comment

I think this is not the correct answer of your questin, but it can help you http://www.linuxconfig.net/2009/11/16/file-server-with-samba-and-ftp-in-freebsd.html

share|improve this answer
add comment

Samba has two ways of setting perms for an uploaded file:

  1. Without UNIX extensions: preset file/directory mask is used
  2. With UNIX extensions (which probably MacOS client has): that allows clients to control file perms

Here's the lines you should add to config file (smb.conf):

# For case 1: no UNIX extensions
create mask = 0644
directory mask = 0755
# For case 2: override UNIX extensions
force create mode = 0644
force directory mode = 0755

(Should be placed BEFORE any share definition goes: this looks like [share name] in square braces and a couple of indented lines. These sets will then apply to all shares you have)

Also read about force group and force user in man smb.conf, if you need it.

share|improve this answer
    
So by placing the commands under "case 1" in the global section of my smb.conf file, I'll be able to force Mac clients to observe set permissions? Sorry I'm new to using Samba and editing the configuration file. –  synchronicity Nov 4 '09 at 1:46
    
Me too, but i've read the whole man smb.conf recently :)) Place the whole snippet in your smb.conf file BEFORE any share definition goes: their names are given in square brackets [share_name]. These lines then will apply to all shared folders in config file. –  kolypto Nov 4 '09 at 1:52
    
create mask and force create mode stand for perms that newly created files will have. directory mask and force directory mode specifies perms for new directories. Cheers! :) –  kolypto Nov 4 '09 at 1:54
    
Keep in mind that many applications create new files every time you save. –  Zoredache Nov 4 '09 at 2:26
    
These commands did work for disallowing the mac client from rewriting the permissions, but not from ignoring the initial permissions on the file. It seems that any permissions allowing the group to read are interpreted as read and write (i.e., 700 locks the file but 740 allows the user to read AND write to it). Thanks so much for this snippet, its really close to what I need! Any other ideas? –  synchronicity Nov 12 '09 at 19:24
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.