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
I'm unsure about the correct component. Changing it to smbclient now. Please correct me if that's wrong. Thanks!
you're not re-exporting an NFS file system via Samba are you ?
No. I've tested this on a regular UFS volume with logging enabled.
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
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.
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
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
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
severity should be determined by the developers and not the reporter.
If it's still broken in 3.5, please reopen. 3.0 isn't supported anymore.