Eingesetzte Samba-Version: 3.5.4 Beim Update eines Kundensystems ist aufgefallen, dass auf Samba-Dateifreigaben von Microsoft Office aus (getestet mit Excel) nicht ordentlich gespeichert werden kann. Der Benutzer erhält die Meldung, dass nicht ausreichend Speicherplatz auf dem Dateisystem zur Verfügung steht. Mit dem Programm smbclient habe ich auf der Kommandozeile folgende Meldungen beim Hochladen einer Datei erhalten: smb: \tests\> put ps.txt postup.sh NT_STATUS_NOT_SUPPORTED closing remote file \tests\postup.sh Testweise habe ich auf dem XFS-Dateisystem eine Datei mit einem EXT3-Dateisystem angelegt und darauf ein Share platziert. Dort kam beim Hochladen die übliche Meldung, dass die Datei erfolgreich gespeichert wurde.
Auch berichtet an Ticket#: 2010091310011679
Welcher Kernel wurde eingesetzt? 2.6.18 oder 2.6.32?
Eingesetzte Kernel-Version: 2.6.18
root@samba-38-1:~# uname -a Linux samba-38-1 2.6.18-ucs155-686 #1 SMP Wed May 19 16:40:34 UTC 2010 i686 GNU/Linux root@samba-38-1:~# smbclient -U Administrator \\\\samba-38-1\\Administrator Enter Administrator's password: Domain=[TEST] OS=[Unix] Server=[Samba 3.5.4] smb: \> put x.txt NT_STATUS_NOT_SUPPORTED closing remote file \x.txt smb: \> root@samba-38-1:~# uname -a Linux samba-38-1 2.6.32-ucs11-686-bigmem #1 SMP Fri Jul 30 17:54:39 UTC 2010 i686 GNU/Linux root@samba-38-1:~# smbclient -U Administrator \\\\samba-38-1\\Administrator Enter Administrator's password: Domain=[TEST] OS=[Unix] Server=[Samba 3.5.4] smb: \> put x.txt putting file x.txt as \x.txt (1,7 kb/s) (average 1,7 kb/s) smb: \> Das bedeutet mit Kernel 2.6.32 funktioniert es wieder.
Nach dem Downgrade auf Samba 3.3.10 funktioniert der Upload.
Das scheint das hier zu sein: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515941 Aus dem Samba strace: utimensat(AT_FDCWD, "x.txt", {{1289981751, 766721000}, {1289988416, 729565000}}, 0) = -1 ENOSYS (Function not implemented) <0.000026> Upstream Mail-Thread: http://lists.samba.org/archive/samba-technical/2010-November/074607.html
utimensat() wurde in 2.6.22 als Syscall eingeführt und steht nicht zur Verfügung wenn der 2.6.18-Kernel verwendet wird. Solange Samba auf einem System übersetzt wurde, auf dem Kernel und glibc mit 2.6.32 übersetzt wurden, wird von Samba trotzdem versucht utimensat() zu verwenden. Samba sollte statt einer Prüfung zur Compile-Zeit idealerweile eine Laufzeitprüfung implementieren; wenn ein Dummyaufruf von utimensat() ENOSYS zurückliefert, ist das dem aktuellen Samba-System utimensat() nicht verfügbar und der alternative Codepfad (über futimens() oder was auch immer) kann verwendet werden.
Created attachment 2833 [details] master.try-other-methods-if-utimensat-is-not-supported-ret.patch
Created attachment 2834 [details] v3-5.try-other-methods-if-utimensat-is-not-supported-ret.patch
I have attached the patch: master.try-other-methods-if-utimensat-is-not-supported-ret.patch If utimensat returns ENOSYS the other utime-methods are used instead. Should apply cleanly to the v3-5-*, v3-6-*, and master branches. This fixes the issue. Also attached is the patch: v3-5.try-other-methods-if-utimensat-is-not-supported-ret.patch This is the same change plus an analogous change for the function copy_reg(). Should apply cleanly to the v3-5-* branches.
Created attachment 2838 [details] 0001-try-other-methods-if-utimensat-is-not-supported-ret.patch > > but doing that correct would be a bit tricky. In > > vfswrap_fs_capabilities() we also need to know that utimensat() doesn't > > work to initialize p_ts_res correctly. A test utimensat() call would > > actually be required to set p_ts_res right, too. POSIX does not even > > mention that this call may fail with ENOSYS. > > > > I would prefer that people with utimensat resulting in ENOSYS should get > > a big warning in the log files: "never us a glibc which is much more > > recent than your kernel." This is a well known problem of Debian systems > > with a way too old XEN kernel. Old kernels with new glibc are not > > supported by their maintainers. People should just not do this - the lack > > of utimensat() is just the most obvious place of brokenness, I guess > > there are more, more subtle brokennesses waiting to be discovered. > > You are right, the results are not known if the kernel is too old for the > glibc. Janek will create a new patch which adds the warning and he will > also check vfswrap_fs_capabilities. I think this would be the best. This is the patch with the check in vfswrap_fs_capabilities and a log message added.
Der Patch von Janek ist eingebaut, allerdings kommt die Warnung erst ab Debug Level 3.
(In reply to comment #12) > Der Patch von Janek ist eingebaut, allerdings kommt die Warnung erst ab Debug > Level 3. In 2.4-1 funktioniert das Speichern mit 2.6.18 wieder in Verbindung mit einem XFS Dateisystem und samba 3.5.4. Getestet mit Windows XP SP3 in Verbindung mit Office2007 und smbclient. Folgende Meldung in der Log (bei debuglevel 3): [2010/11/22 11:00:44.851447, 3] modules/vfs_default.c:146(vfswrap_fs_capabilities) vfswrap_fs_capabilities: utimensat returns ENOSYS. never us a glibc which is much more recent than your kernel. Changelogeintrag ist vorhanden - verified
UCS 2.4-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".