permissions issues on file server

Question

Level 1

17 points

permissions issues on file server

I recently upgraded our Mac Mini (Late 2014) to El Capitan (10.11.4) and OS X Server 5.1 from Yosemite and Server 4.

The only services that we have running are File Sharing and TimeMachine. We use this machine as a file server for our research group. We have no issues connecting and reading/writing files from our Mac clients, and mostly don't have issues from the PC Clients (all running Windows 7). EXCEPT:

Some programs return permissions issues when accessing the file server. One program can't write to the .INI files (although the user can open and write to the .INI files through a standard text editor); another program claims that any path is an invalid or non-existent directory (although you can navigate there from the program, and see it fine through Windows Explorer).

I have checked permissions, and all users have FULL CONTROL on the share.

Does anyone have any thoughts or suggestions? Much appreciated.

OS X El Capitan (10.11.4), OS X Server 5.1

Posted on Mar 24, 2016 2:54 PM

Reply

Answer 1

Mar 24, 2016 5:04 PM in response to honu_girl

Windows is far more sensitive to path and file names than OS X. Any chance you are using spaces, punctuation, special characters, etc. in your file/folder names? If you are stating the issues appear manifest through specific applications, it may be the specific application that is unable to properly handle the path. Not all Windows applications can handle unicode paths and character lengths. See here for some ugly details: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

Try creating a new share with no spaces or special characters. Then create content either at the root of the share or in a shortly named folder (once again no spaces, special characters, etc). Try you apps with this short path and see if it is either a naming or length issue.

Hope this helps

Reid

Apple Consultants Network

Author - "El Capitan Server – Foundation Services"

Author - "El Capitan Server – Control & Collaboration"

Author - "El Capitan Server – Advanced Services"

Reply

Answer 2

honu_girl Author

Level 1

17 points

Mar 26, 2016 12:03 PM in response to Strontium90

Thanks for the suggestion, Strontium90. Unfortunately, that doesn't seem to be the issue. I was pretty sure that wasn't it - I have naming habits held over from days long ago when I worked in Unix - but I just verified by creating a new share, etc., as you suggested, and it resulted in the same errors.

In case it helps, the programs we're having issues with are IHS Petra (a specialized program for geoscience research) and Esri's ArcGIS programs (something a great many people use). Both programs worked as expected prior to upgrading to Server 5.1 (from Server 4). IHS Petra gives an error code specific to file permissions when trying to write to the .INI file (although it can create a new one, it can't then write to it) and the program can write out other file types to the server. ArcGIS acts like it can see the folders and files on the server (e.g., you can navigate to them within the program), but when you try to access one it claims it's an invalid path or filename and suggestions verifying it exists/has correct permissions.

As these two programs are Windows-only, this appears to be some issues between how the Mac server is setting the permissions and the Windows 7 machines are perceiving the permission. As I stated earlier, the programs and paths worked fine in previous versions of Server, and only appear to have these difficulties now that we are using Server 5.1

Thanks for any and all suggestions.

Reply

Answer 3

cdhw

Level 4

3,594 points

Mar 26, 2016 1:05 PM in response to honu_girl

This is probably a question for the developers of the third-party applications. Does the System Log in Console.app show anything relevant when the error occurs?

A problem I've encountered in the past, which this resembles, is a path that looks fine (no spaces or strange characters) but when mounted on the client exceeds some length-limit hard-coded into the application hence 'invalid path or filename'.

C.

Reply

Answer 4

honu_girl Author

Level 1

17 points

Mar 26, 2016 2:22 PM in response to cdhw

The paths did not change from when it was working (in Server 4) to now when it's not (Server 5). The 3rd party programs have not been updated - the only change has been updating the Server.app to Server 5. Even generating new, very short paths hasn't solve the problem.

I've contacted support for both the 3rd party software packages. So far, they've been as confused as I have been - they've not seen this issue before (although one swears we are the only organization who has ever contacted them that uses a Mac file server).

Here's the only messages I received in the system.log when I recreated the error through the programs:

Mar 26 16:13:04 reddwarf sandboxd[143] ([933]): rpcsvchost(933) deny file-read-data /usr/libexec

Mar 26 16:13:04 reddwarf sandboxd[143] ([933]): rpcsvchost(933) deny file-read-metadata /usr/libexec

Mar 26 16:13:38 reddwarf servermgr_status[527]: idle exit

Mar 26 16:13:38 reddwarf Server[366]: Dispatcher: servermgr_status plugin disconnected

Mar 26 16:14:08 reddwarf ntpd[202]: drift PPM:64.848 -> 70.711

Mar 26 16:14:49 reddwarf mds[75]: (DiskStore.Normal:2382) 4001 1.000083

I am well and truly stumped on this. Thanks for any help and advice!

Reply

Answer 5

cdhw

Level 4

3,594 points

Mar 26, 2016 4:22 PM in response to honu_girl

Are any of those messages are any of those messages generated every time and at the same time that the problem occurs?

One possibility is that the intense disk activity that occurs when you upgrade the OS has provoked a disk problem. Do the logs show any 'disk i/o' errors? Have you checked the disk with Disk Utility? Another is that the third-party software messes around trying to write lock files when it opens the .INI and does not have write access to wherever these are going.

C.

Reply

Answer 6

honu_girl Author

Level 1

17 points

Mar 28, 2016 6:50 AM in response to cdhw

Thanks so much for your reply! Here's where I'm at now:

I checked the disks with Disk Utility, and ran first aid, when I first discovered the issue. Unfortunately, the problem persisted. Thanks for the reminder to check again.

More info from looking at the system.log: NO errors in the system.log when one program fails to write. The other program has these messages at the same time it fails:

sandboxd[143] ([36753]): rpcsvchost(36753) deny file-read-data /usr/libexec

sandboxd[143] ([36753]): rpcsvchost(36753) deny file-read-metadata /usr/libexec

I suspect that it does have something to do with lock files or opportunistic locking and somehow not having the correct permissions. However, I don't know how to overcome that... again, any suggestions would be greatly appreciated.

Reply