WebDav Mac OS X problems

[Sander Cox]

Hi,

I just setup an Apache2 server for WebDav with SVN. I can read the
contents of the repository just fine but when I try to add some new
file I get an error in my apache 2 log an my Mac starts complaining:

[Sat Aug 13 01:12:05 2005] [error] [client 10.0.2.216] Failed to
create new lock. [500, #1]
[Sat Aug 13 01:12:05 2005] [error] [client 10.0.2.216] Can't chmod '/
Storage/subversion/db/locks/aeb': Operation not permitted [500, #1]
[Sat Aug 13 01:12:06 2005] [error] [client 10.0.2.216] Failed to
create new lock. [500, #1]
[Sat Aug 13 01:12:06 2005] [error] [client 10.0.2.216] Can't chmod '/
Storage/subversion/db/locks/c72': Operation not permitted [500, #1]

The /Storage/subversion/db/locks directory has 777 chmod permissions
and is owned by the account of the webserver so I don't know why it
would want to be running chmod on the file and have absolutely no
idea why it is complaining it isn't allowed to change the permissions
on the file.

I'm using apache2.0.54, subversion 1.2.1 and Mac OS X 10.4.2

Furthermore I see that Mac OS X is writing the resource forks ._xxx
files as well. Would it be possible to prevent this from happening as
I don't see need for these files for 90% of the files that are going
to be checked into subversion.

Best regards,
Sander Cox

[Ryan Schmidt]

Post by Sander Cox
I just setup an Apache2 server for WebDav with SVN. I can read the
contents of the repository just fine but when I try to add some new
[Sat Aug 13 01:12:05 2005] [error] [client 10.0.2.216] Failed to
create new lock. [500, #1]
[Sat Aug 13 01:12:05 2005] [error] [client 10.0.2.216] Can't chmod
'/Storage/subversion/db/locks/aeb': Operation not permitted [500, #1]
[Sat Aug 13 01:12:06 2005] [error] [client 10.0.2.216] Failed to
create new lock. [500, #1]
[Sat Aug 13 01:12:06 2005] [error] [client 10.0.2.216] Can't chmod
'/Storage/subversion/db/locks/c72': Operation not permitted [500, #1]
The /Storage/subversion/db/locks directory has 777 chmod
permissions and is owned by the account of the webserver so I don't
know why it would want to be running chmod on the file and have
absolutely no idea why it is complaining it isn't allowed to change
the permissions on the file.
I'm using apache2.0.54, subversion 1.2.1 and Mac OS X 10.4.2

What is /Storage? Sounds like it's not a local volume but rather
something like a Samba share or AppleShare volume, where commands
like chmod may not work so well. Can that be? People here often talk
of storing repositories on NFS, which I've heard works fine, as long
as the repository is FSFS and not BDB, but I've not heard of anyone
trying Samba or AppleShare, if that's what you're doing.

Post by Sander Cox
Furthermore I see that Mac OS X is writing the resource forks ._xxx
files as well. Would it be possible to prevent this from happening
as I don't see need for these files for 90% of the files that are
going to be checked into subversion.

I assume we're talking about a working copy here. Mac OS X only
creates the "AppleDouble" ._ files on file systems that do not
natively support multiple forks. AFAIK you cannot prevent Mac OS X
from doing so. But if you use a Mac file system like HFS+ for your
working copy, then the resource fork will be stored as a fork of the
file, and no separate ._ file will be created. When you check in,
only the data fork will be transmitted.

At work, I need to have my working copies on a Samba share, so I
see ._ files all the time. I mentally ignore them in file listings on
the command line, and tell Subversion to ignore them too. Works fine.

[Sander Cox]

Post by Ryan Schmidt

Post by Sander Cox
I just setup an Apache2 server for WebDav with SVN. I can read the
contents of the repository just fine but when I try to add some
new file I get an error in my apache 2 log an my Mac starts
[Sat Aug 13 01:12:05 2005] [error] [client 10.0.2.216] Failed to
create new lock. [500, #1]
[Sat Aug 13 01:12:05 2005] [error] [client 10.0.2.216] Can't chmod
'/Storage/subversion/db/locks/aeb': Operation not permitted [500, #1]
[Sat Aug 13 01:12:06 2005] [error] [client 10.0.2.216] Failed to
create new lock. [500, #1]
[Sat Aug 13 01:12:06 2005] [error] [client 10.0.2.216] Can't chmod
'/Storage/subversion/db/locks/c72': Operation not permitted [500, #1]
The /Storage/subversion/db/locks directory has 777 chmod
permissions and is owned by the account of the webserver so I
don't know why it would want to be running chmod on the file and
have absolutely no idea why it is complaining it isn't allowed to
change the permissions on the file.
I'm using apache2.0.54, subversion 1.2.1 and Mac OS X 10.4.2

What is /Storage? Sounds like it's not a local volume but rather
something like a Samba share or AppleShare volume, where commands
like chmod may not work so well. Can that be? People here often
talk of storing repositories on NFS, which I've heard works fine,
as long as the repository is FSFS and not BDB, but I've not heard
of anyone trying Samba or AppleShare, if that's what you're doing.

It's just how I called the directory on the system, it's not a
special mount point for anything.

Post by Ryan Schmidt

Post by Sander Cox
Furthermore I see that Mac OS X is writing the resource
forks ._xxx files as well. Would it be possible to prevent this
from happening as I don't see need for these files for 90% of the
files that are going to be checked into subversion.

I assume we're talking about a working copy here. Mac OS X only
creates the "AppleDouble" ._ files on file systems that do not
natively support multiple forks. AFAIK you cannot prevent Mac OS X
from doing so. But if you use a Mac file system like HFS+ for your
working copy, then the resource fork will be stored as a fork of
the file, and no separate ._ file will be created. When you check
in, only the data fork will be transmitted.
At work, I need to have my working copies on a Samba share, so I
see ._ files all the time. I mentally ignore them in file listings
on the command line, and tell Subversion to ignore them too. Works
fine.

No I'm talking about the direct WebDAV usage of Mac OS X. When you do
a "Apple+K" in the Finder you can enter the https://...../svn-
repository/" and directly browse over the copy of your repository.
Whenever you drag-and-drop a file to this WebDAV mount point, Mac OS
X tries to make two files in the SVN repository and then the above
errors appear and Mac OS X tells me something went wrong.

Best regards,
Sander Cox

[Ben Collins-Sussman]

Post by Sander Cox
[Sat Aug 13 01:12:05 2005] [error] [client 10.0.2.216] Failed to
create new lock. [500, #1]
[Sat Aug 13 01:12:05 2005] [error] [client 10.0.2.216] Can't chmod
'/Storage/subversion/db/locks/aeb': Operation not permitted [500, #1]
[Sat Aug 13 01:12:06 2005] [error] [client 10.0.2.216] Failed to
create new lock. [500, #1]
[Sat Aug 13 01:12:06 2005] [error] [client 10.0.2.216] Can't chmod
'/Storage/subversion/db/locks/c72': Operation not permitted [500, #1]

I have no problem mounting an svn repository as a DAV share on my OS
10.4 machine.

Looking at those errors above, it looks like one of two things to me:

1. you don't really have mod_dav_svn 1.2 installed. You might want
to open a repository directory URL in your browser and see if that's
what's really being reported in the page footer.

2. you have some sort of permissions problem: the apache process
doesn't have read-write permission within repos/db/locks/ somehow.

[Sander Cox]

Post by Ben Collins-Sussman

Post by Sander Cox
[Sat Aug 13 01:12:05 2005] [error] [client 10.0.2.216] Failed
to create new lock. [500, #1]
[Sat Aug 13 01:12:05 2005] [error] [client 10.0.2.216] Can't
chmod '/Storage/subversion/db/locks/aeb': Operation not
permitted [500, #1]
[Sat Aug 13 01:12:06 2005] [error] [client 10.0.2.216] Failed
to create new lock. [500, #1]
[Sat Aug 13 01:12:06 2005] [error] [client 10.0.2.216] Can't
chmod '/Storage/subversion/db/locks/c72': Operation not
permitted [500, #1]

2. you have some sort of permissions problem: the apache process
doesn't have read-write permission within repos/db/locks/ somehow.

OK I did some more tests and found that when the locks directory was
owend by the webuser that was not enough. It also needed to be owned
by the webservers GROUP. Now that I've changed that it is working.

Personally I still feel like this is a bug, but now I at least know
what the problem was.

Best regards,
Sander Cox

[Ben Collins-Sussman]

Post by Sander Cox
OK I did some more tests and found that when the locks directory
was owend by the webuser that was not enough. It also needed to be
owned by the webservers GROUP. Now that I've changed that it is
working.
Personally I still feel like this is a bug, but now I at least know
what the problem was.

Where's the bug? Every bit of svn documentation states that the
server process (whether it be apache or svnserve) needs complete read/
write access to the entire repository. As the administrator, it's
your responsibility to make this happen. There's nothing subversion
can do to help.

This means understanding how ownership and permissions work on your
particular operating system and filesystem. If you have a complaint
to file, it's probably best sent to whatever Apple engineers designed
HFS. :-)

[Sander Cox]

Post by Ben Collins-Sussman

Post by Sander Cox
OK I did some more tests and found that when the locks directory
was owend by the webuser that was not enough. It also needed to be
owned by the webservers GROUP. Now that I've changed that it is
working.
Personally I still feel like this is a bug, but now I at least
know what the problem was.

Where's the bug? Every bit of svn documentation states that the
server process (whether it be apache or svnserve) needs complete
read/write access to the entire repository. As the administrator,
it's your responsibility to make this happen. There's nothing
subversion can do to help.

It has. But why on earth should it need to have access as it's group
as well. I don't think that should be required. Maybe it is indeed a
bug in the Apple file system but I truly think it is a subversion
problem. As now I won't be able to mix usage of a file:/// repostiory
which I could because I was a member of the group the dir was owned
by. But that is something I don't really care about in my situation.

Regards,
Sander Cox

[Kevin T. Broderick]

Post by Sander Cox
It has. But why on earth should it need to have access as it's
group as well. I don't think that should be required. Maybe it is
indeed a bug in the Apple file system but I truly think it is a
subversion problem. As now I won't be able to mix usage of a
file:/// repostiory which I could because I was a member of the
group the dir was owned by. But that is something I don't really
care about in my situation.

If the apache process was running as the user that owned the files,
then it wouldn't be a problem. What you're seeing would suggest that
whichever user owns the file is *not* the user as whom apache is
running. As a result, that user's ownership of the files is
irrelevant. However, the user owning the process attempting to
access the repository *is* (by what you've said) a member of the
subversion group (or whichever group now owns the files). This is
not a subversion bug; it is the way Unix-like permissions work. It
can be annoying, as it will sometimes result in weird errors if a
process is not running as who you think it is. If you can confirm
that the user owning the files does not have access to them with o+wr
set, then that's an Apple bug.

(incidentally, the best way to test such problems is often to su to
the user running the daemon process in question, i.e. sudo su apache,
and then attempt to access the files. You may need to give the user
a usable shell first, of course.)

Kevin Broderick
***@boltonvalley.com

[Dave Camp]

Post by Kevin T. Broderick

Post by Sander Cox
It has. But why on earth should it need to have access as it's
group as well. I don't think that should be required. Maybe it is
indeed a bug in the Apple file system but I truly think it is a
subversion problem. As now I won't be able to mix usage of a
file:/// repostiory which I could because I was a member of the
group the dir was owned by. But that is something I don't really
care about in my situation.

If the apache process was running as the user that owned the files,
then it wouldn't be a problem. What you're seeing would suggest
that whichever user owns the file is *not* the user as whom apache
is running. As a result, that user's ownership of the files is
irrelevant. However, the user owning the process attempting to
access the repository *is* (by what you've said) a member of the
subversion group (or whichever group now owns the files). This is
not a subversion bug; it is the way Unix-like permissions work. It
can be annoying, as it will sometimes result in weird errors if a
process is not running as who you think it is. If you can confirm
that the user owning the files does not have access to them with o
+wr set, then that's an Apple bug.
(incidentally, the best way to test such problems is often to su to
the user running the daemon process in question, i.e. sudo su
apache, and then attempt to access the files. You may need to give
the user a usable shell first, of course.)

If the Unix permission model is not fine grained enough for you, and
you and running Tiger, ACL's might solve your problem. An ACL would
allow you to give permissions to multiple groups or users.

man chmod

Dave