Samba share randomly unable to move files/folders

permissionsmb

I'm having strange permissions issues with my OSX 10.8.4 server. I stopped using the Apple v2.2.1 server app due to numerous issues & now have samba 3.6.15 installed via Macports, which mostly works ok except…
Every now & then OSX asks for a password when trying to move specific files or folders from one place to another (within the same volume) Entering the users own password doesn't work, he is already logged on to the server as himself & is able to move other folders, save files & otherwise work ok.
When I do a 'get info' to look at the permissions for that file, it has 'staff – read/write' even though staff is not set as owner group for that folder & none of the users have staff as their primary group id.
If I expand 'details' it is 'com.apple.desktopservices' that is asking for the password
Guessing 'staff' has something to do with it although any suggestions appreciated!
Thanks,

Best Answer

After a bit of research I've come up with a workable solution - at least I'm not changing it for the time being.
Check 'ignore ownership' is unticked on the external volume where the share resides.

Change the users primary group id from 'staff' to custom group id

sudo dscl . -change /Users/lmessi PrimaryGroupID 20 567

Remove all ACLs from External drive 'Disk1'

chmod -RN /Volumes/Disk1

[if you get any errors, try recursive unlock files beforehand]

sudo chflags -R nouchg /Volumes/Disk1

change group ownership recursively for the group 'design'

sudo chgrp -R design /Volumes/Disk1

You can check ownership with ls -gl

ls -gl /Volumes/Disk1

Then my smb.conf file looks something like this

[global]
    socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
    unix extensions = no

        guest ok = No
        read only = No
        force group = design

    create mask = 664
        force create mode = 664
        security mask = 664
        force security mode = 664
        directory mask = 2775
        force directory mode = 2775
        directory security mask = 2775
        force directory security mode = 2775

[Share1]
        comment = Share1
    path = /Volumes/Disk1/Share1
        valid users = mickey, donald
        admin users = mickey, donald

Considerations

For the partition, in its entirety, at the server you grant read and write privileges to everyone:

may be comparable to guest access, which does not require authentication.

Consider the following possibilities:

some communication, or attempted communication, by Windows 7 may be anonymous, without authentication (whether/how such communications would be logged by the server in a non-Server build of the OS, I don't know)
writes, or attempted writes, by Windows 7 are inappropriate for something at/around the root of the partition.

Suggestions

Increase the verbosity of logging for SMB

This may be easier to achieve with a Server build of the OS.

Diagnosis at the server when the client perceives a problem

Enable the stackshot daemon then use the key chord for sysdiagnose

Preparation: enable the daemon

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.stackshot.plist

When the problem occurs: use the key chord for sysdiagnose.

For at least ten seconds after the chord, touch nothing.

After Finder brings to front the result of sysdiagnose: decompress the archive, consider the files that comprise the diagnosis.

References

stackshot(1) OS X Manual Page

sysdiagnose(1) OS X Manual Page

Windows – Odd permissions issues on Windows Share

We have had a very similar (if not the same) problem ever since we upgraded our server to Windows 2008 R2. (WinServer 2003 was fine.) However, the main symptom we encountered, is somewhat different:

We work in a mixed Mac / PC environment. Desktop operators work on Mac only, whereas our backend services are Windows based. Also some manual operations are done on Windows 7.

We call our problem "Ghost Folders". These are folders, that are inaccessible even for Windows Administrator account. Windows displays no privileges for anyone! Even admin user cannot see folder permissions or owner - nor can ownership be taken by Administrator. Total lockdown.

Such folders are created under following circumstances:

A windows share is mounted on Mac by SMB://<IP-address> notation.
Mac or Windows user attempts to move or delete a folder with some files inside.
Mac Finder gives error "No access" or "Insufficient privileges", as does Windows.
Windows Server shows the folder as with no permission for anyone. This folder will disappear by itself some time later (!!) Time span can be anything from a few minutes to several hours.
On Mac, the UNIX 'ls -la' command shows the folder permissions as normal. However 'ls -la' for the folder contents lists nothing. Not even the "." or ".." for 'current' and 'upper-level' folders.

This scenario can be repeated at will - Deletion can be attempted either on Mac or Windows.

Similar behavior is also seen when attempting to save (overwrite) a file from a Mac application. This will give permissions error - and the original file disappears from the server. This suggests a successful deletion of the original file, but failed write of the new content.

This scenario will only take place if at least one Mac has the share mounted and any folder of the share is open in Finder. A share that is not accessed by any Mac does not produce this problem.

We have sketchy evidence that the initial deletion attempt (when unsuccesful) will actually (or partially) delete the folder from the Windows file system. We have seen deletion apparently to succeed on Windows Explorer. However, the Mac SMB connection appears to somehow, as if "re-create a shadow" of the folder - or "deny" the deletion after the fact, bringing the folder back to Windows file system, but with null permissions.

We would appreciate if someone checks for this behavior on their systems, if you see the same chain of events as we do. It may help us all to more accurately pinpoint the source of this elusive problem.

Any input will be greatly appreciated.