Snow Leopard挂载目录偶尔更改权限

Question

I have a smb mounted directory: /Volumes/myshare

This was mounted via Finder "Connect to Server..." with smb://myservername/myshare

Everything good so far.

However, when I try to access the directory via PHP (running under Apache), it fails with permission denied about 10% of the time. By this I mean that repeated accesses to my page sometimes result in a failure. My PHP page looks like:

<?php
  $cmd = "ls -la /Volumes/ 2>&1";
  exec($cmd, $execOut, $exitCode);
  echo "<PRE>EXIT CODE = $exitCode<BR/>";
  foreach($execOut as $line) {
    echo "$line <BR/>";
  }
  echo "</PRE>";
?>

When it succeeds it looks like:

EXIT CODE = 0
total 40 
drwxrwxrwt@  4 root   admin    136 Jun 14 12:34 . 
drwxrwxr-t  30 root   admin   1088 Jun  4 13:09 .. 
drwx------   1 galen  staff  16384 Jun 14 09:28 myshare 
lrwxr-xr-x   1 root   admin      1 Jun 11 16:05 galenhd -> / 

When it fails it looks like:

EXIT CODE = 1
ls: myshare: Permission denied 
total 8 
drwxrwxrwt@  4 root  admin   136 Jun 14 12:34 . 
drwxrwxr-t  30 root  admin  1088 Jun  4 13:09 .. 
lrwxr-xr-x   1 root  admin     1 Jun 11 16:05 galenhd -> / 

OTHER INFO:

I'm working with the PHP (5.3.1), and Apache server that comes out of the box with Snow Leopard.

Also, if I write a PHP script that loops and retries the "ls -la.." from the command-line, it doesn't seem to fail.

Nothing is changing about the code and/or filesystem between succeeds and fails, so this appears to be a truly intermittent failure.

This is driving me crazy. Anyone have any idea what might be going on?

Thanks, Galen

Answer 1

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 (ie 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 (ie 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? https://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 2

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

Answer 3

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 (ie 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 4

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...