Windows sometimes sets the read-only attribute for directories it wants to mark
as "special". In my case, it's for a Briefcase folder to do file
synchronization between my WinXP machine and my Mac OS X notebook. However,
smbd apparently does not honor requests from a client to set a directory to
read-only. (I've even tried manually doing so with the attrib command.)
If the Briefcase folder is not reported read-only, Windows does not treat it as
"special" and the file sync options aren't available. However, if the directory
is manually set to read-only via chmod, everything looks great in Explorer --
except that now files can't be added or updated, because the directory's
read-only. (A read-only directory in DOS does not have the same write
restrictions as in UNIX.)
Scott Gifford provided a "readonly hack" smb.conf option to get around this:
However, this patch is for Samba 2.0.7.
Can Scott's patch, or something similar, be incorporated into future releases?
I am unsure if "store dos attributes" solves this problem, but it doesn't help
for systems with no extended attribute support. I'd even take a option that
reported a directory as read-only if a particular file was found in it, a la:
report directory readonly = /desktop.ini/
(It's a major performance hit, but worth it for me.)
Note that this is similar to bug #796. I've tried changing attributes via the
Properties sheet as well, and it doesn't work.
I am also having the same problem:
When I try to change the hidden attribute of directories that are on an ext3
filesystem shared partition, through a windows XP station, the bit is not set.
However it works for the files for all the attributes system/hidden/read-
only/archive without any problem. It's like if this option would have been
forgotten for the directories while implementing that function for the files.
To my opinion it should be working the same way for both.
Read only directory attributes are fully supported if you map the DOS attributes
Set the following in your smb.conf :
map hidden = no
map system = no
map archive = no
ea support = yes
and the problem is fixed.
This only flies if your filesystem supports extended attributes. As far as I
know, Mac OS X does not. (Off the top of my head, only BSD supports EA.)
I'm reopening the bug because what you're describing is not a general solution.
Sorry. You'll have to get a system that supports EA's :-)
Or perhaps talk to Apple.