Ticket #26094 (closed defect: invalid)
mit-scheme port fails with permission denied error
| Reported by: | jkh@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | base | Version: | 1.9.99 |
| Keywords: | Cc: | mk@… | |
| Port: |
Description (last modified by blb@…) (diff)
This does not happen for all ports (I am able to build scheme48 successfully, for example) but, in this example, mit-scheme fails with a rather bizarre error. Debug output is as follows:
jkh@wunga-> sudo port -d -v install mit-scheme
Password:
DEBUG: Changing to port directory: /Users/jkh/Src/macports/dports/lang/mit-scheme
DEBUG: OS darwin/10.4.0 (Mac OS X 10.6) arch i386
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: universal_variant is false, so not adding the default universal variant
DEBUG: changing euid/egid - current euid: 0 - current egid: 0
DEBUG: egid changed to: 4294967294
DEBUG: euid changed to: 4294967294
DEBUG: could not read "/Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile": permission denied
while executing
"file mtime ${portpath}/Portfile"
(procedure "open_statefile" line 46)
invoked from within
"open_statefile"
(procedure "check_variants" line 29)
invoked from within
"check_variants activate"
invoked from within
"$workername eval check_variants $target"
(procedure "mportexec" line 7)
invoked from within
"mportexec $workername $target"
Error: Unable to execute port: could not read "/Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile": permission denied
To report a bug, see <http://guide.macports.org/#project.tickets>
Change History
comment:2 Changed 3 years ago by jmr@…
- Status changed from new to closed
- Component changed from ports to base
- Version changed from 1.9.1 to 1.9.99
- Resolution set to worksforme
Right, the default macportsuser setting in macports.conf is now nobody. Make sure your ports tree is fully readable by that user, or change it to root like it used to be if you prefer.
comment:3 follow-up: ↓ 5 Changed 3 years ago by jkh@…
- Status changed from closed to reopened
- Resolution worksforme deleted
I'm afraid you may be on the wrong track:
jkh@wunga-> ls -l /Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile -rw-r--r-- 1 jkh staff 2730 Aug 15 09:22 /Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile
As you can see, this Portfile is readable by all, yet the euid/guid changing scheme is evidently flawed since setting macportsuser to ANY user other than root (I tried several, altering permissions accordingly) does not work. Did you try this with sudo, as in my example? I suspect a bad sudo/macports interaction here. Again, this is also with trunk - please repro with trunk and macportsuser NOT set to root (which works fine - I checked that also).
comment:4 Changed 3 years ago by jmr@…
I am using trunk with macportsuser=nobody, running with sudo, and a file:// source; and mit-scheme builds for me. So given that your permissions are OK, I don't know why it would fail for you.
comment:5 in reply to: ↑ 3 Changed 3 years ago by blb@…
Replying to jkh@…:
I'm afraid you may be on the wrong track:
jkh@wunga-> ls -l /Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile -rw-r--r-- 1 jkh staff 2730 Aug 15 09:22 /Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile
Yeah, but what about sudo -u nobody ls -l /Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile? Odds are you ran into what I did, a parent up the chain isn't readable by nobody (in my case it was an immediate subdir of my $HOME).
comment:7 Changed 22 months ago by mk@…
egid and euid look rather wild, don't they?
Another example of this problem can be found in the duplicate #30332
comment:8 Changed 22 months ago by jmr@…
Looks like the correct uid/gid for nobody to me. The test suggested by blb in comment:5 is still relevant. If you can't perform the operation in a shell as the user used by MacPorts, then it's not a problem with anything MacPorts is doing.
comment:9 Changed 22 months ago by mk@…
Thanks, jmr, I hadn't spotted that hint.
Yes, I can verify that a similar test does fail in my case.
markos-imac:~ marko$ ls /Users/marko/WC/MacPorts/ports/kde/kmymoney4/Portfile.my /Users/marko/WC/MacPorts/ports/kde/kmymoney4/Portfile.my markos-imac:~ marko$ sudo -u nobody ls -l /Users/marko/WC/MacPorts/ports/kde/kmymoney4/Portfile.my ls: /Users/marko/WC/MacPorts/ports/kde/kmymoney4/Portfile.my: Permission denied
Turns out the folder WC in my HOME was private. I hadn't done this myself, not that I know of. Looks like that some unknown application modified the permissions. Great find, thanks again, jmr!
I think this ticket can be considered closed.
comment:10 Changed 22 months ago by jmr@…
- Status changed from reopened to closed
- Resolution set to invalid


Same thing happened to me, I'm guessing you're on trunk instead of 1.9.1; seems to be because port is now using nobody instead of root in certain phases, and some path up to /Users/jkh/Src/macports/dports/lang/mit-scheme probably doesn't let nobody see things. I just did a mode 711 on one of my directories, and things worked out after.