http access to external usb drive

Question

JRSnell Author

Level 1

4 points

http access to external usb drive

I’m working on this problem too.

The problem likely stems from SIP (System Integrity Protection).

SIP ‘protects’ /System/Volumes/Data which is a partition of the first internal drive.

All USB drives are auto mounted to /Volumes which is rooted at … /System/Volume/Data.

Apache (mod-mpm I think), requires execute permissions on every directory from Target-Directory back up to root (I’ve seen this assertion in several threads, but do not know it to be a fact). if this is the case, then it explains why you can follow symlinks in terminal bur Apache refuses to create directory listings.

In troubleshooting the problem, I’ve mounted the USB drive manually into /Users (which is not SIP controlled), where it worked, but will not survive a reboot. I don’t want to create a script to remount the drive after reboot unless its the only solution.

If anyone has a solution to this problem, that doesn’t break SIP or TCC, I’m all ears! Ideally (if my analysis is correct), it will be a tweak to httpd.conf or to one of the Apache security modules.

Mac mini, macOS 12.6

Posted on Jan 2, 2023 5:43 PM

Reply

Answer 1

JRSnell Author

Level 1

4 points

Jan 3, 2023 2:02 PM in response to JRSnell

root@SRV1 sandbox # cat rootless.conf | grep /Volumes

* /System/Volumes/Data

This says that TCC should NOT be protecting /Volumes (which is mounted at /System/Volumes/Data/Volumes (as though that's not confusing at all ... )

With the USB Drive mounted at /Volumes/Data I can read and write anything with Terminal or Finder. When I put a link in my Apache root (/www), Safari displays a "You don't have permission" web page. (I've tried this with. and without <Alias> and matching <Directory> directives in http.conf).

In the Apache error log:

Operation not permitted: [client 67.61.213.205:58455] AH00132: file permissions deny server access: /Library/WebServer/Documents/Private/Data/index.html

In the System Log (Errors only):

{ID: com.apple.sandboxd, PID[221], auid: 0, euid: 0, binary path: '/usr/libexec/sandboxd'} attempted to call TCCAccessRequest without the com.apple.private.tcc.manager.check-by-audit-token entitlement

Refusing TCCAccessRequest for service kTCCServiceSystemPolicyRemovableVolumes from client /usr/sbin/httpd in background session

And that right there is why USB drives no longer work as targets for Apache directory listings ...

But it may not be TCC's fault. Remember I can read and write just fine with other tools, so this appears to be the result of Apache being an "unsigned app". Which makes a little sense because it's not an App Store app. However it was distributed on MacOS and OSx ... so from a certain point of view, Apple could have signed Apache, but may not have realized that a web server might want to produce directory listings on very large USB connected drives? You would think by now (its been a couple of OSx releases, and a couple of years) that a solution to this problem would have been published - or maybe I'm just not asking the right questions of Google?

Anyhow that's where this problem is as of today (20230103).

I tried mounting the USB drive into /Users/Shared

Reply

Answer 2

Jan 3, 2023 3:45 PM in response to JRSnell

Sorry I did not read all the details in your post but to respond to your initial post, to serve web pages from a directory, that directory needs to be allowed access in the apache conf file. Apache will not serve files from just any location.

Reply

Answer 3

JRSnell Author

Level 1

4 points

Jan 3, 2023 4:03 PM in response to BobTheFisherman

Thanks for the reply BobTheFisherman.

I'm sure I didn't explain all the troubleshooting I've done - including aliasing, linking, and directory configs. None of which have the slightest effect on the problem.

I'm certain I've got the problem down to something to do with the way Apache accesses a drive that is protected by SIP and/or TCC. It is most likely a code signing problem.

However it may be related to me changing the machine name in settings (which did not change the name in all the locations where it is stored ... ). Name change may have also damaged some certificates, which may play into how SIP and TCC operate.

I'm also pretty sure that if I were to rebuild the computer from bare metal this problem might not exist. Its an old machine (Late 2012) that reached its last OS update (Catalina 10.15.7) some time ago. It's had a decade of updates, software installs, de-installs, etc. and I really should rebuild it.

Before anyone asks, I'm running Apache 2.4.53

Reply