# /usr/ports directory inaccessible



## francis (Mar 22, 2011)

*[ thread split off into separate topic - Mod. ]*

Is it normal, that some ports directories (e.g /usr/ports/www/firefox36) have permissions which does not allow user (from wheel group) to check out e.g distfiles or Makefiles or simply... get there? I am asking you because yesterday I saw a little, red X on some directories. One of them is firefox36 dir (latest firefox-3.6.15,1). It is strange, because a couple of days ago, I was able to enter there and check all files. Now I can not, even via console [1]. There is several directories with similar right access in whole ports tree - most in the cad category.

What I did over the last few days? Update ports via portsnap utility, clean distfiles from /usr/ports/distfiles/ directory with portmaster. That's all. I never had a such situation, where I can not enter to the some application directory in the ports tree because of acces permissions. Or maybe I never put my attention on it? Or, finally, maybe it is because of what *phoenix* wrote?; _"The first month or so after a FreeBSD release sees *a lot* of churn in the ports tree._" But my problem relates to a computer running FreeBSD 8.1 Release. I am so confused.

Best regards!

[CMD=""][1] $ cd /usr/ports/www/firefox36[/CMD] 
	
	



```
/usr/ports/www/firefox36: Permission denied.
```


----------



## ondra_knezour (Mar 22, 2011)

francis said:
			
		

> ...but my problem relates to a computer running FreeBSD 8.1 Release. I am so confused.



There is onle one ports tree for all releases and development versions of FreeBSD, so on 8.1 you will get exactly what on 8.2.

As about permission issue - I had never seen something you described, I will consider local error as first possibility. Try download clean ports tree with 
`# portsnap fetch extract`


----------



## francis (Mar 23, 2011)

Ok, I wanted to do it yesterday, but I thought that maybe someone here, will have some answers. So, downloading clean ports tree caused that I do not have access to each directory in ports tree! Each directory has little, red x. So, I decided to remove whole ports tree and extract once again:

`# rm -fr /usr/ports/*` 
`# portsnap fetch extract` 

But this time, the ports directory in /usr/ location has little, red x! Now, I can not enter/click even on /usr/ports/ directory! Also look what is happen, when I try to download ports snapshot;

`# portsnap fetch`

```
Looking up portsnap.FreeBSD.org mirrors... 5 mirrors found.
Fetching snapshot tag from portsnap6.FreeBSD.org... done.
Ports tree hasn't changed since last snapshot.
No updates needed.
```
But fetching Ports with portsnap utility (of course with fetch and extract options) Ports Tree are extracted! What? Without prior download? I do not know what's going on. At this point I do not have /usr/ports/ directory because everything fails. For the very first time I have similar problems with ports. What to do?


----------



## ondra_knezour (Mar 23, 2011)

francis said:
			
		

> But `# portsnap fetch extract` command extracts ports tree! What? Without prior download?



Porstnap extracts previously downloaded tarball, because

```
Looking up portsnap.FreeBSD.org mirrors... 5 mirrors found.
Fetching snapshot tag from portsnap6.FreeBSD.org... done.
Ports tree hasn't changed since last snapshot.
No updates needed.
```


----------



## DutchDaemon (Mar 23, 2011)

francis, use the *[file]* tags for directory/file names, not a color.


----------



## francis (Mar 23, 2011)

Sorry *DutchDaemon*, you mentioned this already before, but... by what happens with the ports - just forgot about it. *ondra_knezour*; yes, I know that. So, I tried to remove the /var/db/portsnap and then run portsnap utility with _fetch_ option. I thought I would succeed because the system downloads ports (I mean 64MB file). But when I try to extract it, again port directory in /usr/ports/ has little, red x.

I thought that maybe it is because of umask settings? So I set the value again at *27* (yes, I know that default is 22) via /etc/login.conf file and of course run cap_mkdb command, but still no effect. I set the same value even in user and root .profile files.

I do not know what to do. Sorry for "attach" to this topic, but I was thinking that answer will be simpler.


----------



## DutchDaemon (Mar 23, 2011)

francis said:
			
		

> Sorry for "attach" to this topic, but I was thinking that answer will be simpler.



Thread split off.


----------



## francis (Mar 23, 2011)

OK, thanks for split off. You know what? Everything has happened because of umask settings! I decide to check it via umask(2) command. And I was so suprised that this value is different from that set in .profile, and /etc/login.conf files. I do not know why this values does not changed (despite that I changed it in those files). I changed this value to *27* using umask command, and then download ports tree once again with portsnap and _fetch/extract_ options.

Thanks to all. But still I wonder why this problem appeared yesterday? I changed a Umask value long time ago. Maybe I noticed this, because yesterday I tried to get there "by clicking" as a normal user? Maybe.


----------



## Maredelamer (Aug 31, 2011)

*Thank you francis.*

Thank you francis. I had the same situation with the ports tree permissions behaving oddly but more crippling an improper root umask would seem to change the permissions on rather important directories as well, i.e. after making a few ports (via ports-mgmt/portmaster) I've had x11-wm/xfce4 doing some very odd things due to /usr/local/etc/xdg being unreadable due to, I think, root's umask of 22; Regardless an example of what this looked like for me:
`# ls -l /usr/local/etc/ | grep xdg`

```
drwx------  8 root  wheel    512 Aug 29 11:05 xdg
```
Which I have been continually fixing via
`# cd /usr/local/etc/`
`# chmod +rx ./xdg`
This results in (no surprise),
`# ls -l /usr/local/etc/ | grep xdg`

```
drwxr-x---  8 root  wheel    512 Aug 29 11:05 xdg
```
Which I _think_ is right at any rate and at least allows XFCE4 to function again.

Regardless I seem to have quite a number of directories with questionable permissions now. I anticipate that at worst rebuilding whatever stops working or complains will get things back into a proper shape now that root's umask is set to 27.


----------

