Re: [Samba] NFS quotas: truncated files without warning
Opened bug in RHs bugzilla ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244848 ) En/na simo ha escrit: On Mon, 2007-06-18 at 12:21 -0700, Jeremy Allison wrote: On Mon, Jun 18, 2007 at 08:48:09PM +0200, SER.RI-TIC - David Losada wrote: Hi Jeremy, actually, I have adapted your patch for applying to the current RHEL4 Samba release (samba-3.0.10-1.4E.12.2). Would you mind to check if I have made any flagrant mistakes? If anyone reads this and decides to try it, please bear in mind it's experimental. Summary of what I have modified from your patch: * no patch for smbd/aio.c , because it's just not there yet in this release * in smbd/fileio.c:sync_file() , doesn't check for the sync always directive, the check's not originally there * in smbd/fileio.c:sync_file() , for accessing the fd, it's just fsp-fd, not fsp-fh-fd * in smbd/reply.c:reply_write() , ignored the hunk around CHECK_WRITE(fsp), because in this release that check is not made * took into account that the checking of conditions for forcing synchronization (lp_strict_sync, lp_sync_always, write_through) hadn't yet been refactored into the fileio.c:sync_file() function If patching from a vanilla samba-3.0.10 release, should apply the smbd_deferred_open_backport patch first. I'm also attaching it for convenience. If your patch makes it to next Samba official release, and this patch receives your blessing, could we put them in consideration of RedHat for an errata? The fact it helps to avoid silent data corruption in an scenario like ours, should be interesting for them. This work looks good - it's not a complex change. The fix will definately be in 3.0.25b, I'll let Simo pick up the change for RH for their older versions if he thinks it's warrented. I'd really prefer an entry in RHs bugzilla to be able to easily pick it up :-) Simo. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Quota Question
Hi Mike, maybe your first problem is the same problem we are fighting with here. See the NFS quotas: truncated files without warning thread. The problem we are having happens because the kernel generates the quota error _not_ while writing the file, but when _closing_ it. Samba correctly propagates the error, but windows clients ignore it at that moment. In the thread there's a patch that might be useful for you. kind regards, En/na Mike Alborn ha escrit: Hi, I have several Samba servers running on Linux (Debian Etch) machines using 2.6.18 kernel. The Samba shares are all on an XFS filesystem, with user and group quota support. I have three problems/questions: 1. When a user hits their quota limit, they get a disk full error. 2. When a user checks the free space of the share, they see the space on the entire share, rather than the space left under their quota. 3. Windows doesn't seem to acknowledge the soft limit at all. Only the first item is really a problem (the disk full error), as it is a source of confusion, both for the user and for the helpdesk. Isn't Samba supposed to return a quota exceeded message when the user has exceeded their quota? If so, why doensn't it? I am able to see and set quotas through the Quota tab in Windows, and 'smbd -b' shows WITH_QUOTAS, so I assume the package is compiled with quota support. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
Hi Jeremy, just tried your patch on 3.0.25a (it applied cleanly) and configured the suggested directives (strict allocate, strict sync, sync always). This way, the clients I have tested (Win2K with clear-text authentication, smbclient) get notified immediately about the lack of available quota. Relevant log excerpts: (smbclient) [2007/06/11 22:24:12, 5] smbd/reply.c:reply_write_and_X(3159) reply_write_and_X: sync_file for samba-3.0.10-1.4E.12.2.src.rpm returned NT_ST ATUS_DISK_FULL [2007/06/11 22:24:12, 3] smbd/error.c:error_packet_set(106) error packet at smbd/reply.c(3160) cmd=47 (SMBwriteX) NT_STATUS_DISK_FULL (Win2K) [2007/06/11 22:25:16, 5] smbd/reply.c:reply_write_and_X(3159) reply_write_and_X: sync_file for rvtls_putty.reg returned NT_STATUS_DISK_FULL [2007/06/11 22:25:16, 3] smbd/error.c:error_packet_set(106) error packet at smbd/reply.c(3160) cmd=47 (SMBwriteX) NT_STATUS_DISK_FULL What do you think are the chances of backporting it to 3.0.10 and 3.0.23c? I am willing to do the effort, just would like to know your opinion on it, since you seem to know the affected code very well ;) It would be nice very nice for us if we could send it to RedHat so they consider to issue an errata to RHEL4 and 5. About limiting the syncy behaviour just to the space allocation operation... I think maybe we are not interested in persuing it by now and we could sacrifice performance for safety. thank you, En/na Jeremy Allison ha escrit: On Fri, Jun 15, 2007 at 08:23:49PM +0200, SER.RI-TIC - David Losada wrote: mmm... well, it doesn't seem to be working like that in the version that ships with RHEL4. I will get around to try it on a fresh build on monday and report to you about it. Apply this patch and let me know if it fixes it (will be in 3.0.25b). Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
Hi Jeremy, actually, I have adapted your patch for applying to the current RHEL4 Samba release (samba-3.0.10-1.4E.12.2). Would you mind to check if I have made any flagrant mistakes? If anyone reads this and decides to try it, please bear in mind it's experimental. Summary of what I have modified from your patch: * no patch for smbd/aio.c , because it's just not there yet in this release * in smbd/fileio.c:sync_file() , doesn't check for the sync always directive, the check's not originally there * in smbd/fileio.c:sync_file() , for accessing the fd, it's just fsp-fd, not fsp-fh-fd * in smbd/reply.c:reply_write() , ignored the hunk around CHECK_WRITE(fsp), because in this release that check is not made * took into account that the checking of conditions for forcing synchronization (lp_strict_sync, lp_sync_always, write_through) hadn't yet been refactored into the fileio.c:sync_file() function If patching from a vanilla samba-3.0.10 release, should apply the smbd_deferred_open_backport patch first. I'm also attaching it for convenience. If your patch makes it to next Samba official release, and this patch receives your blessing, could we put them in consideration of RedHat for an errata? The fact it helps to avoid silent data corruption in an scenario like ours, should be interesting for them. kind regards, En/na Jeremy Allison ha escrit: On Fri, Jun 15, 2007 at 08:23:49PM +0200, SER.RI-TIC - David Losada wrote: mmm... well, it doesn't seem to be working like that in the version that ships with RHEL4. I will get around to try it on a fresh build on monday and report to you about it. Apply this patch and let me know if it fixes it (will be in 3.0.25b). Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
Hi Jeremy, thank you for the tip. Unfortunately, this hasn't proved succesful.. how I tested it: from W2K, as an user with a completely full quota, I drop a 11788 byte file into the share. It produces the following system calls in the server: write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 3596) = 3596 (4096+4096+3596 = 11788) so my Samba is verifying the availability of storage space through the write() system call, which doesn't generate NFS quota errors, ugh. The thing is that an fsync() after these write() calls would probably get me the NFS quota error... maybe it's implemented this way in a newer Samba release? kind regards, En/na Jeremy Allison ha escrit: On Fri, Jun 15, 2007 at 06:44:47PM +0200, David Losada wrote: Hi, we have some Samba instances serving files from a bunch of NFS exports provided by a NAS appliance. Coming from Solaris, we recently have been testing to run our Samba servers on Linux (RHEL 4, Samba 3.0.10-1.4E.12.2). One caveat we didn't expect is that, on Linux, NFS quota errors are reported on calls to close() or fsync(), but not on calls to write(). Through smbclient, we have checked that Samba correctly reports the error to the client (NT_STATUS_DISK_FULL closing remote file ...). However, Windows 2000 clients silently ignore this error when closing the file, leaving the file truncated with no warning to the user (something we really don't want to happen!) We have tried strict sync = yes and sync always = yes configuration directives, to no avail. Have also googled trying to find an answer, but couldn't find one. I don't think we are the only ones with this kind of setup.. anyone has an idea of how to handle this scenario correctly? Try strict allocate = yes to which will cause Samba to actually allocate space on a Windows client set allocation size call - this should fail if over quota and be at the right place for the Windows clients to see it. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
mmm... well, it doesn't seem to be working like that in the version that ships with RHEL4. I will get around to try it on a fresh build on monday and report to you about it. However, I can imagine it would result in quite a big performance hit all around. If the 'syncy' behaviour could be restricted to the set allocation size call, maybe that would be a little bit less painful ;) Pity about linux NFS client semantics, it was working nice in Solaris. Maybe should nag the kernel mantainer for this code ;) Right, looking at performance, we should be serving SMB from the NAS appliances. Will need to look again at the possibilities these appliances offer. kind regards and thanks again, En/na Jeremy Allison ha escrit: On Fri, Jun 15, 2007 at 10:48:58AM -0700, Jeremy Allison wrote: On Fri, Jun 15, 2007 at 07:44:22PM +0200, SER.RI-TIC - David Losada wrote: Hi Jeremy, thank you for the tip. Unfortunately, this hasn't proved succesful.. how I tested it: from W2K, as an user with a completely full quota, I drop a 11788 byte file into the share. It produces the following system calls in the server: write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 3596) = 3596 (4096+4096+3596 = 11788) so my Samba is verifying the availability of storage space through the write() system call, which doesn't generate NFS quota errors, ugh. The thing is that an fsync() after these write() calls would probably get me the NFS quota error... maybe it's implemented this way in a newer Samba release? Yes, that's what we do (I wrote the code :-). I'll add code to force an fsync after these writes if strict sync is also set. I'll post the patch for 3.0.25 once I've done it. Actually, I've checked the code and this should already be being done. The secret is to set : strict allocate = yes strict sync = yes sync always = yes So force the flush - normally we only do the fsync if the client asks for it on the write call. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] config of failover machine backing multiple samba print servers
Hello, in our organization we have a number of print servers scattered across several organizational units and departments. These servers are configured in a similar fashion (Samba 3+CUPS, raw print queues, point-and-print drivers for clients, authentication backend in a centralized directory). We had this idea of trying to set-up a machine in our central offices, for providing fail-over printing service. Upon notification of the failure of a print server, a manual procedure would be performed and the failover machine would impersonate the failed print server. We hoped to achieve this by configuring samba with multiple virtual servers. We would enable them selectively (upon real server failure). We want the possibility of having more than one of them enabled at the same time (in case of a specially bad day). However, we found no joy in our attempts. Impersonating a print server requires replicating the ntprinters.tdb (and possibly other .tdb files). The problem for us is that, in a Samba instance, just one ntprinters.tdb is queried, not possible to keep a separate one for each virtual server. I'm not sure if adding the content of all the ntprinters.tdb keys in a single ntprinters.tdb would work (and don't know how to do it) Is all this just a bad idea? Or maybe can be done somehow? cheers, David -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
