Bug 2434 - largefiles broken (locking?) under Solaris 9 with non-local users (winbind)
largefiles broken (locking?) under Solaris 9 with non-local users (winbind)
Status: RESOLVED WONTFIX
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.13
Sparc Solaris
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on: 2428
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-09 08:10 UTC by Walter Haidinger
Modified: 2010-04-26 03:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Walter Haidinger 2005-03-09 08:10:26 UTC
Any attempt to save files  larger than 2GB result in the message 
"Error writing file: NT_STATUS_OK".

Even a loglevel of 10 doesn't show _any_ hints. This is really odd.

At first, I suspected sendfile because of bug #2432 but the following 
is true regardless if sendfile is compiled in or not. Perhaps this is all
related to bug 2428 (https://bugzilla.samba.org/show_bug.cgi?id=2428)?

Samba 3.0.10, 3.0.11 and 3.0.12pre1 all show identical results.
Compiled with gcc 3.4.2 under Solaris 9/sparc (Generic_117171-17).

Tried builds with sendfile enabled/disabled and, optional, off64_t detection
forced. Neither combination thereof worked, though.

Build process:
# ./configure --prefix=/usr/local/samba3 --with-sendfile-support --with-quotas
--with-sys-quotas --with-acl-support --with-libsmbclient --with-winbind
--with-automount 
# make 

# uname -a
SunOS teststor 5.9 Generic_117171-17 sun4u sparc SUNW,Sun-Fire-V440
# smbclient //127.0.0.1/large -d3
smb: \> put 2.1gb
dos_clean_name [\\2.1gb]
Error writing file: NT_STATUS_OK
putting file 2.1gb as \2.1gb (7386.1 kb/s) (average 7386.1 kb/s)
smb: \> 

The resulting file on the share is always a bit larger than 2GB.
In particular, the alyways seem to have the same size, i.e. a
2254856192 byte file (2.1gb) is always truncated to 2148185088 bytes.
The difference changes with the file size, though.

Of course, large files are no problem if Samba is _not_ used!

If there is any additional information needed, please reply to this bug.
Thanks in advance!

Regards, Walter
Comment 1 Walter Haidinger 2005-03-10 01:52:35 UTC
I'm unsure about the correct component. Changing it to smbclient now.
Please correct me if that's wrong. Thanks!
Comment 2 Gerald (Jerry) Carter 2005-03-14 08:45:04 UTC
you're not re-exporting an NFS file system via Samba are you ?
Comment 3 Walter Haidinger 2005-03-14 16:44:19 UTC
No. I've tested this on a regular UFS volume with logging enabled.
Comment 4 Walter Haidinger 2005-03-23 08:20:42 UTC
I've just tested 3.0.12 and it still doesn't work under Solaris 9/sparc
(Generic_117171-17, SunFire-V440). This time it fails with:
Error writing file: NT_STATUS_FILE_LOCK_CONFLICT

However, on another V440, only running an older cluster of Recommended Patches 
(5.9 Generic_117171-09), otherwise similar hardware, 3.0.12 does work! :-o

So, this might be an Solaris only issue after all! 
Here is probably the wrong place to ask, but before marking this bug INVALID:
Can somebody verify or reproduce this?

Walter
Comment 5 Walter Haidinger 2005-03-23 09:55:06 UTC
Ok, different machine (SunFire V250) with SunOS 5.9 Generic_117171-12:
3.0.12 and large files works there too! I'm getting nuts!
I'll install latest Recommended Patches on the V250 now and try again.
Comment 6 Walter Haidinger 2005-03-24 11:05:23 UTC
Short story: 3.0.12 works on all three machines now.

After reinstalling Solaris 9 from scratch with latest Recommended Patches on the
"initally failing" V440, Samba 3.0.12 has no problems with large files anymore.

Also, it could _not_ verify that is a patchlevel issue. I'm guessing that
supsequent installations (perhaps fibre drivers, SamFS or else) somehow screwed
up the Solaris 9 installation. This needs to be investigated further, of course.

Anyways, in all probability, this is _not_ a Samba issue!
Therefore, I apologize for creating this bugzilla entry in the first place!

Before finally marking this bug INVALID, I'll have Samba join the domain again 
and run a final test. That's the only difference left regarding to Samba.

Walter
Comment 7 Walter Haidinger 2005-03-29 07:59:55 UTC
Bad news: I've done some more testing with Samba 3.0.13 and the bug persists! 
Good news: There are some more details about the bug!

Summary: Putting large files (>2 GB) will fail with either        
NT_STATUS_FILE_LOCK_CONFLICT or NT_STATUS_OK if 
* Samba is a domain member (security=domain), 
* the connecting user isn't local (not listed in /etc/passwd and not mapped) 
* and has been authenticated with winbind (from PDC).

That is, if a non-local member is used utilizing winbind (through nsswitch.conf,
uid/gid for domain members), like allowing access to a share, .e.g.:
[share]
   valid users = NTDOM/DOM_USER

That's the only combination for which I can reproduce failure of putting large
files. Unfortunately that's the desired one...

In particular, security=user or security=domain with local users work. Please
note that all working tests in my previous comments have been done with
security=user!

I've verfied this behaviour on two almost identical SunFire V440 machines (each
4 Sparc CPUs, 8GB RAM, similar storage arrays), both running Solaris 9/sparc
with up-to-date patches (Generic_118558-03).
I can NOT reproduce this under Linux/x86 (SuSE-9.1, Samba 3.0.13), so I 
think it is a platform dependant problem. 

I'm updating the subject and Samba version accordingly. Please change component
too if it is necessary and/or tell me if I should close this bug and open
another bug instead! Thanks!

I'd appreciate any hints howto debug this issue further!

Walter
Comment 8 Walter Haidinger 2005-04-04 00:27:40 UTC
After explicitly setting sendfile = no, I get the following log entry
which doesn't suprise me at all (please see bug #2428 too).

locking/posix.c:posix_fcntl_lock(657)
  posix_fcntl_lock: WARNING: lock request at offset 748259895, length 14793   
  returned an Invalid argument error. This can happen when using 64 bit lock 
  offsets  on 32 bit NFS mounted file systems.

I'm still puzzled why this depends on the authentication method, though...

Walter
Comment 9 Gerald (Jerry) Carter 2006-04-20 08:03:32 UTC
severity should be determined by the developers and not the reporter.
Comment 10 Stefan Metzmacher 2010-04-26 03:17:40 UTC
If it's still broken in 3.5, please reopen.
3.0 isn't supported anymore.