Bug 2661 - OS/2 EAs not working properly
OS/2 EAs not working properly
Status: ASSIGNED
Product: Samba 3.0
Classification: Unclassified
Component: nmbd
3.0.20
All Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-27 15:49 UTC by Steve Wendt
Modified: 2009-09-17 15:44 UTC (History)
3 users (show)

See Also:


Attachments
zip of level 10 debug log (26.26 KB, application/zip)
2005-04-27 15:50 UTC, Steve Wendt
no flags Details
ea-support-off-copycmdline-file-witheas (26.83 KB, text/plain)
2005-04-28 09:37 UTC, thomas schönemann
no flags Details
ea-support-off-copycmdline-file-withouteas (23.79 KB, text/plain)
2005-04-28 09:40 UTC, thomas schönemann
no flags Details
ea-support-off-copywps-file-witheas (109.89 KB, text/plain)
2005-04-28 09:40 UTC, thomas schönemann
no flags Details
ea-support-off-copywps-file-withouteas (110.51 KB, text/plain)
2005-04-28 09:41 UTC, thomas schönemann
no flags Details
ea-support-on-copycmdline-file-witheas (12.97 KB, text/plain)
2005-04-28 09:41 UTC, thomas schönemann
no flags Details
ea-support-on-copycmdline-file-withouteas (23.80 KB, text/plain)
2005-04-28 09:41 UTC, thomas schönemann
no flags Details
ea-support-on-copywps-file-witheas (87.71 KB, text/plain)
2005-04-28 09:41 UTC, thomas schönemann
no flags Details
ea-support-on-copywps-file-withouteas (84.56 KB, text/plain)
2005-04-28 09:42 UTC, thomas schönemann
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Wendt 2005-04-27 15:49:42 UTC
Testing 3.0.15pre2 on a FC3 system, using ext3 with ext_attr attribute enabled.

Copying a file with an EA (os2krnl) produces an error message:
The extended attributes for the file or directory were
discarded because the target file system does not support them.

Using the eautil program (which can split and join EAs from/to files) also
produces similar error messages.  It looks like *everything* has EAs now,
although it is all SELinux stuff, not OS/2 EAs.
Comment 1 Steve Wendt 2005-04-27 15:50:31 UTC
Created attachment 1184 [details]
zip of level 10 debug log
Comment 2 thomas schönemann 2005-04-28 09:37:58 UTC
Created attachment 1188 [details]
ea-support-off-copycmdline-file-witheas
Comment 3 thomas schönemann 2005-04-28 09:40:12 UTC
Created attachment 1189 [details]
ea-support-off-copycmdline-file-withouteas
Comment 4 thomas schönemann 2005-04-28 09:40:37 UTC
Created attachment 1190 [details]
ea-support-off-copywps-file-witheas
Comment 5 thomas schönemann 2005-04-28 09:41:06 UTC
Created attachment 1191 [details]
ea-support-off-copywps-file-withouteas
Comment 6 thomas schönemann 2005-04-28 09:41:21 UTC
Created attachment 1192 [details]
ea-support-on-copycmdline-file-witheas
Comment 7 thomas schönemann 2005-04-28 09:41:32 UTC
Created attachment 1193 [details]
ea-support-on-copycmdline-file-withouteas
Comment 8 thomas schönemann 2005-04-28 09:41:46 UTC
Created attachment 1194 [details]
ea-support-on-copywps-file-witheas
Comment 9 thomas schönemann 2005-04-28 09:42:06 UTC
Created attachment 1195 [details]
ea-support-on-copywps-file-withouteas
Comment 10 thomas schönemann 2005-04-28 09:59:18 UTC
sorry for enterin the same text as on bug 1979 
(which is a dublicate of this bug i guess)

i installed samba3.0.15 on either our sun solaris9 host (ufs filesystem
without ea support) as on a gentoo-linux-system with reiserfs and user_xattrs
enabled.

on both environments i see the EA problem as follows:

1)  "ea enabled = yes" 
-i can see,open,delete all files/folders via os/2 commandline and via WPS.
-if i copy files via command-line (file without EAs) it works.
-if i copy files via command-line (file with EAs) i get "access denied" BUT the
file is created with zero-size (without eas). Copying again succeeds (because
the file already exists)
-if i copy via WPS (file without EAs) i get "sys0266 file not copied" - but the
file is created with null-size as above
-if i copy via WPA (file with EAs) i get "extended attributes not supported ..."
and then "sys0266 file not copied"


2) ea enabled = no
things are quite more strange with the WPS:
-everything via command-line works well (ok - no EAs) 
-the WPS behaves strange, no error messages (except for files with EA "extended
attributes are not supported...") , i can copy files to and back the samba
folder - but the folder view stores its information somewhere in nirvana:
if i delete icons - they remain as do the files. If i copy or delete something
via commandline - the folder-view does NOT recognize that.
Reopening the folder does not change anything


above i attached to this bug 8 files (smbd.log, debuglevel 10)

for all 8 copy-file operations i mentioned above:

4 x with "ea support = on" in smb.conf
  1 x commandline copy a file with EA
  1 x commandline copy a file without EA
  1 x WPS copy a file with EA
  1 x WPS copy a file without EA

4 x with "ea support = off" in smb.conf
  1 x commandline copy a file with EA
  1 x commandline copy a file without EA
  1 x WPS copy a file with EA
  1 x WPS copy a file without EA


thomas
Comment 11 Jeremy Allison 2005-05-02 08:51:20 UTC
I've taken a look at this and everything appears to be working (on the "witheas"
cases) until the "[f]setxattr" call - which fails with "access denied". I'm
rather stuck unless I can reproduce this and debug the smbd process dynamicly.
Is there any way you can do this ? I can try and get OS/2 at home to test this -
what *exact* version of OS/2 are you using ?

As for the non-ea-support case, what do you want smbd to do ? Accept open with
EA and setea calls and ignore the EA's ? Or return errors ? Please help me
understand what the correct semantics you want in this case.

Jeremy.
Comment 12 Steve Wendt 2005-05-04 16:47:49 UTC
(In reply to comment #11)
> what *exact* version of OS/2 are you using ?

I don't think the IBMPEER stuff changed much between OS/2 3.0 and 4.52.  So, any
release from the last 10 years is probably good enough.

> As for the non-ea-support case, what do you want smbd to do ? Accept open with
> EA and setea calls and ignore the EA's ? Or return errors ? Please help me
> understand what the correct semantics you want in this case.

In the non-Samba case, in addition to "WP ROOT. SF" there is also a "WP SHARE.
SF" created, which I assume has something to do with the WPS problems that
Thomas is reporting.  Unfortunately, I know little about how this is supposed to
work.
Comment 13 thomas schönemann 2005-05-06 03:13:30 UTC
(In reply to comment #11)
> I've taken a look at this and everything appears to be working (on the "witheas"
> cases) until the "[f]setxattr" call - which fails with "access denied". I'm
> rather stuck unless I can reproduce this and debug the smbd process dynamicly.
> Is there any way you can do this ? I can try and get OS/2 at home to test this -
> what *exact* version of OS/2 are you using ?
> 
> As for the non-ea-support case, what do you want smbd to do ? Accept open with
> EA and setea calls and ignore the EA's ? Or return errors ? Please help me
> understand what the correct semantics you want in this case.
> 
> Jeremy.


in lack of any technical documents about what os/2 really does underneath, i'll
try to describe what i think it does:

if the filesystem does NOT support EAs, os/2 stores its EAs in the file 
"WP ROOT. SF", in the root of the drive/filesystem. If that file does not exist,
it will be created on first need. This is the way on local FAT filesystems, as
on  a shared drive from a windows server or in former time from a novell netware
server.
I'm not sure, but i think os/2 will use this way, if the setea-calls return errors.


for the "witheas" case you wrote above, that the "[f]setxattr" call fails with
"access denied". What could that mean? Did i something wrong compiling Samba on
linux, so samba does not work with the EAs on reiserfs?
If i set and read EAs on the linux-samba-server with the "set/getfattr" command 
everything works.


short todo-list
- "witheas" case:
Is there anything wrong with the samba-config here at my site?

- "without eas" case
Solution (1) : smbd returns errors for ea-calls and we will see if os2 then goes
the "WP ROOT. SF" path
Solution (2) : smbd ignores EAs at all - returns no errors and does not store
anything. All eas will get lost like in samba 2, but that normally will not
disturb too much.


thomas
Comment 14 thomas schönemann 2005-05-06 03:59:12 UTC
jeremy,

if it could help you, we can try to give you VNC access to one of our
os/2 clients here in our net. 
so you have an entire os/2 client and via telnet/ssh from that to the
test-linux-smaba system.
So you can make your testing/debugging without setting up an os/2 system at 
home.


thomas

Comment 15 Steve Wendt 2005-05-06 10:53:55 UTC
(In reply to comment #13)
> if the filesystem does NOT support EAs, os/2 stores its EAs in the file 
> "WP ROOT. SF", in the root of the drive/filesystem. If that file does not 
> exist, it will be created on first need. This is the way on local FAT 
> filesystems, as on a shared drive from a windows server or in former time from 
> a novell netware server.

This is not correct.  Local FAT file systems use "EA DATA. SF" for extended
attributes, and remote filesystems either support EAs or don't.  "WP ROOT. SF"
is only used by the WPS, not the command line.

> - "without eas" case
> Solution (2) : smbd ignores EAs at all - returns no errors and does not store
> anything. All eas will get lost like in samba 2, but that normally will not
> disturb too much.

I don't see a big problem there.
Comment 16 thomas schönemann 2005-05-09 01:10:31 UTC
> 
> This is not correct.  Local FAT file systems use "EA DATA. SF" for extended
> attributes, and remote filesystems either support EAs or don't.  "WP ROOT. SF"
> is only used by the WPS, not the command line.
> 

yes, i think your are right.

> > - "without eas" case
> > Solution (2) : smbd ignores EAs at all - returns no errors and does not store
> > anything. All eas will get lost like in samba 2, but that normally will not
> > disturb too much.
> 
> I don't see a big problem there.
> 

it has just to be done ;-)
Comment 17 Gerald (Jerry) Carter 2006-04-08 07:43:43 UTC
Cleaning up versions.  There was no 3.0.15 so leaving it in bugzilla 
is causing some confusion.  Moving these nuder 3.0.20.
Originally files against 3.0.15preX.
Comment 18 Björn Jacke 2009-09-17 15:43:45 UTC
Thomas, can you retest with 3.4? Sorry for the delay.