You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Tobias Herp <to...@gmx.de> on 2006/08/09 11:19:13 UTC

can't open file '.../db/transactions/14590-9.txn/node.0.0': Permission denied

Hi, everyone,

(sorry if anyone gets this mail the 2nd time; I waited several hours and couldn't find it in the list)

we have the strange problem that a certain submit fails with the strange error message "can't open file '.../db/transactions/14590-9.txn/node.0.0': Permission denied". I found the question in the web (e.g. at http://svn.haxx.se/users/archive-2006-01/0300.shtml), but so far couldn't find a real answer what could solve the problem.

We run svn 1.2.3 on a SuSE Linux 9.1, behind an Apache 2.0.54, using HTTP basic authentication.

I had a look at the db/transactions directory (ls -l; excerpt:)

drwxrwsr-x  28 root   www 880 2006-08-08 18:45 .
(...)
drw-rwSr--   2 wwwrun www  48 2006-08-08 17:45 14590-17.txn
drwxrwSr--   2 wwwrun www  48 2006-08-08 17:44 14590-16.txn
(...)
drw-rwSr--   2 wwwrun www  48 2006-08-08 17:07 14590-1.txn
drwxrwsr-x   5 root   www 408 2006-08-08 17:06 ..
drwxrwsr-x   2 wwwrun www 168 2006-07-25 16:38 14156-1.txn
drwxrwsr-x   2 wwwrun www 168 2006-06-07 16:16 1644-1.txn
drwxrwsr-x   2 wwwrun www 168 2006-06-27 07:58 1937-1.txn
drwxrwsr-x   2 wwwrun www 168 2006-07-06 16:59 2110-1.txn

There are no more main numbers other than 2110, 1937...14590; I found that only the directories NNNN-1.txn contain files (but /not/ 14590-1.txn). I have no idea why the 14590-N.txn directories have "S" attributes (group executable), while the earlier ones have "s" ...

The additional group executable bit of 14590-16.txn was added manually after try #16 had failed, but this (of course) didn't change anything.

Strange enough, the commit somehow seams to have worked, since I found an incremental dump of revision 14590 later in my backup directory. But now all commits seem to fail.

Any idea anyone what's going on here?

How can we affect the attributes set on the *.txn directories, created by subversion?

Is there a sticky bit which must be set (preferred with appropriate chmod command)?

Thanks a lot in advance!

-- 
Tobias

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: can't open file '.../db/transactions/14590-9.txn/node.0.0': Permission denied

Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Tobias Herp wrote:
> Tobias writes:
>> we have the strange problem that a certain submit fails with the
>> strange error message "can't open file
>> '.../db/transactions/14590-9.txn/node.0.0': Permission denied".
>
> We found the cause of the problem: it was a umask command in
> /etc/profile.local, which set rw rights to user and group, but not x,
> since this would cause every new file to be executable...
>
> We removed the umask there (I'm afraid it will have to be added to
> every single ~/.bashrc instead) and rebooted the server; now all
> works well again.

That's not how umask is supposed to work: umask is a *mask* that is bitwise 
ored with other masks, such as those used for compiling binaries and 
creating directories. 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: can't open file '.../db/transactions/14590-9.txn/node.0.0': Permission denied

Posted by Tobias Herp <to...@gmx.de>.
Tobias writes:
> we have the strange problem that a certain submit fails with the strange
> error message "can't open file '.../db/transactions/14590-9.txn/node.0.0':
> Permission denied".

We found the cause of the problem: it was a umask command in /etc/profile.local, which set rw rights to user and group, but not x, since this would cause every new file to be executable...

We removed the umask there (I'm afraid it will have to be added to every single ~/.bashrc instead) and rebooted the server; now all works well again.
-- 
Tobias

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org