Hi all,

I'm having a curious issue with my new 10.5 server installation. Here's the whole picture:
-Brand new Quad Core Xserve
-Started as Workgroup configuration, but promoted to Advanced
-Bound to Active Directory
-Is OD Master, and the only OD server I have.

We organize our file storage here a little differently than others do- I have a script that queries the database for our accounting system, and when new jobs are created in that database, a folder hierarchy is made in the format
Client
--Job Number
----Department1
----Department2
----Department3

I have permissions set so that users have full control of content within each DepartmentX folder, but no higher. Under AFP, everything works out exactly as we want it to.

When the same account logs in under SMB (which will only be used by my few Windows clients), I see the following symptoms:
-User could create a folder, but can't name it differently than the default. You could make New Folder and New Folder (2), but make a folder and try to rename it, Windows responds with a cannot rename, access denied error.
-Same applies for right-click: New Text Document. Default names are acceptable, renaming isn't allowed.
-New Folder can be opened, and written to. Files here can be saved and renamed at will.

I've tried setting the DEfault permissions to be both "inherit from parent" and Assigning as Read and Write for everyone, with no luck.

Again, the same user accounts logging in under AFP are fine.

Does anyone have a guess what setting I have wrong here?

Thanks.

I am having the exact same problem...

Well, I guess that means either
-we both made the same configuration error
or
-there's something wrong with SMB on 10.5 Server.

I have a case open with Apple for this.

There is a bug in 10.5. ACL are not respected in the SMB shares. and worse: if a user has more than 16 groups assigned, he doesn'T get all the permissions that are assigned to him: everygroup after the 16th is ignored.

Result: SMB server is badly broken in 10.5.

If the effective permission inspector says it's OK, it should be OK. However it's not...

I imagine this has to do with the SMB server actually running as root and attempting to figure out the user permissions unlike the AFP server which spawns a thread with the effective UID of the connected user.

Is running as root new in 10.5?

Not much but just want to add that I've got the exact same problem on a 10.5.1 OD Master. There was mention of fixes to SMB in 10.5.1 but this problem still seems just the same. I can't even see anything pertinent in the logs to know where to start digging.

Skaff.

I think there is also a problem in Leopard Client SMB. I can't always connect to a SMB share on a 10.5 server from a 10.5 client, and when I can I am locked out and have no read or write permission to the folders on the share. I can connect to the same share with the same user and password from a WinXP, a 10.5 client via AFP, and a 10.4 client via AFP and SMB and the ACL's are working. Before I upgraded our servers to Leopard we had W2K3 AD with a 10.4 OD and 10.4 clients bound to AD and OD, all users are in AD. Everything was working pretty well, I had SSO from my bound Mac Clients to any share I had access to and they would mount without having to give my password again. I then upgraded our OD to 10.5, I had to rebuild the OD master because it wouldn't upgrade OD correctly, I was not happy about that, and a couple servers I just did an upgrade on. Now I have what appears to be the same problem for the ACL's not being passed correctly but also appears to be a 10.5 client issue. I also lost SSO from both 10.4 or 10.5, I have to provide my password to get to access to the shares wether they are housed on a Mac or Windows server.

10.5.2 server does not fix the problem :-(

Dammit, when will they fix these major issues ?

I have the same problem myself.
There are even a thread on it at apple:
http://discussions.apple.com/thread.jspa?messageID=6123688&

Yeah, I started that thread too.

I found a workaround via the mac-os-x-Server list:

> The workaround is to append the following lines to /etc/smb.conf:
>
> [global]
> acl check permissions = no
>
> See smb.conf(8) for a detailed explanation of what Samba is trying to
> do. the problem arises because Darwin ACLs are closer to Windows ACLs
> that to POSIX ACLs, so Samba doesn't quite get the access check
> correct on Darwin.

This will tell SMB to disregard ACL's. I'm sure there must be some drawback to that, however. But it does make the server useful for Windows clients, which is better than it is now.

Well as it does seem to somewhat solve the ACL problem, it doesn't solve the problem with POSIX inherit of group permissions not working.

If I set it to 775 it will be 755, whatever I do! But only over SMB, AFP works fine.. as always...

Hi,

I´m hanging here with the same problem. I have set up the server more than one time to see if I made it up.
But it still stays the same. AFP connections OK with all rights, SMB connections with fully different rights.

That is not the way I could learn Mac OS X Server.
So my question is now, what is wrong with samba or am I just stupid.

After messing with my problem some more I found that one of my users could log into the Mac 10.5.2 server via AFP and see one of the shares they had access to but not the other. The only difference I found was that in the POSIX permissions Other was set to Read only on the working one and set to None on the broken one. I set the broken one to Read only and now the ACL permissions work, they get permissions via ACL's because they are in AD. It also solved my access privileges for SMB access, we have had to use SMB instead of AFP because for some reason in 10.5.x AFP speeds are dog slow when copying large files.

I've been having similar problems in 10.5.4

I couldn't figure out for the life of me why one of my users wasn't getting all of his groups when logged into XP, and why on one share he could write but not delete files.

"acl check permissions = no" seems to have solved it.