Snow Leopard mounted directory changes permissions sporadically

Answer 1

Can you check logs of this SMB server? It appears as a SMB error, not yours.

Answer 2

My feeling is that it's probably not related to the SMB server, as I can't reproduce when running manually from the command-line. In other words it seems to only fail when run through the web (i.e. when hitting the apache page).

So it looks to me like it's somehow an apache or "PHP under apache" bug...

Now I'm seeing the page getting stuck in the "permission denied" state. In other words it keeps failing after it fails for the first time. I have also found a series of steps to reproduce, and get out of "permission denied" state:

1) Repeatedly hit the PHP page until it fails (it will stay "failed" after it fails)

2) Once it's failed, performing an ls /Volumes on the command-line will fail.

3) Doing a sudo ls /Volumes does work (i.e. root can see directory). Trying the ls as the normal user still fails though...

4) However (this is the interesting part) doing a sudo ls -l /Volumes on the actually repairs the mount. In other words, after this command both PHP and command-line as the normal user starts working again.

CONCLUSION?

So it seems as it accessing the mount point via PHP/apache (see code above) breaks the mount, changing the permissions, which locks user out. Then root can restore the permissions by issuing a sudo ls -l /Volumes !!!

What is going on here. This is pretty basic code. Surely someone has seen this before...

Perhaps this is related? http://superuser.com/questions/100746/osx-10-6-give-apache2-readwrite-access-to-mounted-windows-share/152473#152473

UPDATE: 2010-06-15: Updated my machine to 10.6.4, which claimed to help with SMB mount issues. However, this did not fix the problem I'm seeing. Looking more and more like an apache issue...

UPDATE: 2010-06-16: If the code is changed to:
$cmd = "ls -a /Volumes/ 2>&1";
(removed -l option) it doesn't fail. In other words the"-l" flag is causing the failures to occur...

UPDATE2: 2010-06-16: Since it's looking like an Apache (on mac?) problem, I've posted to the Apache forum: http://forums.digitalpoint.com/showthread.php?t=1839935

Answer 3

(I'm Galen's IT guy)
Server is Windows 2003 Storage Server x64
File system is NTFS
Folder Permissions are set to Everyone = Full Control
Share permissions set to Everyone = Full Control
Windows event logs show no SMB or security login/logoff errors

Apparently, the same PHP scripts run fine on both Linux and Windows, but not Mac. (Correct Galen?)

Tried setting NTFS permissions & Owner to "Network Service" (as seen in the Snow Leopard/Office 2008 fix) but that didn't help either.

Answer 4

I concur with my IT guy, and I'm almost positive it's not an SMB issue. I know this because when I run tcpdump, there is no network communication during failures. In other words, what is happening is:

1) Apache changes permissions on filesystem in a bad way (i.e. changes permissions of mount dir).

2) Future attempts to access mount fail at OS/File-System level, even before SMB is accessed.

3) Filesystem permissions can be restored via the sudo ls -la /Volumes trick.

Answer 5

Perhaps not an answer, but some more data. I reached this page when researching a similar issue. My Mac runs an Automator script when I log in as User to mount a NAS volume (FileShare) on /Volumes. I tried to symlink FileShare into /Library/WebServer/Documents and after enabling WebSharing was unable to browse it due to permissions (403 error). The permissions looked fine (755).

Did some research and found out that the httpd process was running as the _www user (ps -ef from Terminal). Attempting to ls my symlinked director as _www (sudo -i -u _www ls FileShare) showed that the _www user received Permission denied.

I ended up not fixing the permissions (nothing seemed to work), but rather went to /etc/apache2 and modified httpd.conf to have the httpd server run as user(staff) instead of _www(_www) (Under User/Group settings).

Stopping and restarting the web server made it now run as User instead of _www -- and now it was able to navigate to the symlinked directory...