[Samba] "attrib +R myowndir" fails to write-protect my own dir

[Dragan Krnic]

A trivial case:

executing the following DOS command from the prompt line on a Win2K SP3:

   %windir%\system32\attrib.exe +R H:\dir

can't set the R(eadonly) flag on my home dirs (2.2.7):

   drwxrwsr-x  4  me  users  4096 Nov 27 17:59 .
   drwxr-sr-x  2  me  users  4096 Nov 27 17:59 dir
   -r--r--r--  1  me  users     0 Nov 27 17:59 empty.txt
   drwxr-sr-x  2  me  users  4096 Nov 27 17:27 profile

The relevant settings are:

      create mask = 664
      directory mask = 0775
   [homes]
      valid users = %S
      read only = No
      inherit permissions = No
      directory security mask = 0777
      browseable = No

The packets exchanged very quickly between my WS and the server:

Win2K SP3 Client                  SuSE 8.1/samba 2.2.7 server
================================= ================================
Tr2 Rq Q_PATH_INFO, Path:         Tr2 Rs Q_PATH_INFO
Tr2 Rq FIND_FIRST2, Pattern: \dir Tr2 Rs FIND_FIRST2, Files: dir
NT Create AndX Req, Path: \dir    NT Create AndX Resp, FID: 0x2f70
Tr2 Rq SET_FILE_INFO, FID: 0x2f70 Tr2 Rs SET_FILE_INFO
Close Request, FID 0x270          Close Response
                                  nfs>netbios-ssn[ACK]...

The log at level 3 shows no error:

smbd/process.c:process_smb(878) Transaction 35 of length 79 
smbd/process.c:switch_message(685) switch message SMBtrans2(pid 10017
smbd/trans2.c:call_trans2qfilepathinfo(1702)call_trans2qfilepathinfo: 
            TRANSACT2_QPATHINFO: level = 1004 
lib/util.c:unix_clean_name(387)   unix_clean_name [] 
lib/util.c:unix_clean_name(387)   unix_clean_name [.] 
smbd/trans2.c:call_trans2qfilepathinfo(1734)
            call_trans2qfilepathinfo . level=1004 call=5 total_data=0 
smbd/process.c:process_smb(878)   Transaction 36 of length 98 
smbd/process.c:switch_message(685)switch message SMBtrans2(pid 10017
smbd/trans2.c:call_trans2findfirst(900)   call_trans2findfirst:
            dirtype = 22, maxentries = 1366, close_after_first=1, 
            close_if_end = 1 requires_resume_key = 1 level = 260, 
            max_data_bytes = 16384 
lib/util.c:unix_clean_name(387)   unix_clean_name [/dir] 
lib/util.c:unix_clean_name(387)   unix_clean_name [dir] 
lib/util.c:unix_clean_name(387)   unix_clean_name [./] 
smbd/dir.c:dptr_create(488)   creating new dirptr 256 for path ./,
            expect_close = 1 
smbd/process.c:process_smb(878)   Transaction 37 of length 101 
smbd/process.c:switch_message(685)switch message SMBntcreateX(p.10017
lib/util.c:unix_clean_name(387)   unix_clean_name [/dir] 
smbd/dosmode.c:unix_mode(111)   unix_mode(dir) returning 0664
lib/util.c:unix_clean_name(387)   unix_clean_name [dir] 
smbd/process.c:process_smb(878)   Transaction 38 of length 120 
smbd/process.c:switch_message(685)switch message SMBtrans2 (pid 10017
lib/util.c:unix_clean_name(387)   unix_clean_name [dir] 
lib/util.c:unix_clean_name(387)   unix_clean_name [dir] 
smbd/trans2.c:call_trans2setfilepathinfo(2418)
          call_trans2setfilepathinfo(8) dir info_level=1004 totdata=40 
smbd/dosmode.c:unix_mode(111)   unix_mode(dir) returning 0755 
smbd/process.c:process_smb(878)   Transaction 39 of length 45 
smbd/process.c:switch_message(685)switch message SMBclose (pid 10017) 
smbd/reply.c:reply_close(3148)   close directory fnum=12144 

but the directory remains writeable.

At compile time there were only some warnings about implicit
declarations of functions, "__fork" in "smbwrapper/smbw.c" and many
more with the pattern "smbw_some-syscall" in "smbwrapper/wrapped.c"
but the comment in the file says not to try to get rid of them.

The only other suspect diagnostic was for functions "smbc_telldir"
and "smbc_lseekdir" in "libsmb/libsmbclient.c", lines 2279 and 2320:
cast to pointer from integer of different size, here the lines:

   2279  return (off_t)fe->dir_next;
and
   2320  struct smbc_dirent *dirent = (struct smbc_dirent *)offset;

Setting R-flag on a regular file works, but setting H(idden) or 
A(rchive) flag doesn't.

If "inherit permissions" is changed to "Yes" then not even a regular
file can be write-protected but then H and A flags can be set and
cleared.

I suspect the same problem causes "magic" folder links to lose their
magic, i.e. the R-flag.

Can anyone help?

Yours truly
Dragan


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus