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.
Created attachment 1184 [details] zip of level 10 debug log
Created attachment 1188 [details] ea-support-off-copycmdline-file-witheas
Created attachment 1189 [details] ea-support-off-copycmdline-file-withouteas
Created attachment 1190 [details] ea-support-off-copywps-file-witheas
Created attachment 1191 [details] ea-support-off-copywps-file-withouteas
Created attachment 1192 [details] ea-support-on-copycmdline-file-witheas
Created attachment 1193 [details] ea-support-on-copycmdline-file-withouteas
Created attachment 1194 [details] ea-support-on-copywps-file-witheas
Created attachment 1195 [details] ea-support-on-copywps-file-withouteas
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
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 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.
(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
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
(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.
> > 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 ;-)
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.
Thomas, can you retest with 3.4? Sorry for the delay.
closing due to lack of feedback. Feel free to reopen this bug if this is still reproducable with a modern samba release.