similar to: "WARNING: failed verification -- update retained (will try again)" message

Oeps, forgot the list. > -----Oorspronkelijk bericht----- > Van: L.P.H. van Belle > Verzonden: woensdag 22 mei 2019 16:01 > Aan: 'sambalist at discosucks.it' > Onderwerp: RE: [Samba] Weird Samba/CIFS behavior: client hangs > > Try FQDN in the shares and not \\servername\ that might help. > Most simple to test. > > And OS? > Samba version? >

I've tried straight the IP into the share \\x.y.z.k\, same behaviour. The server is smbd 4.7.6 on Ubuntu 18.04. The client is cifs-utils 6.8.2, samba-common 4.10.0 on Ubuntu 19.04 What i get on dmesg is [ 1395.187394] CIFS VFS: Server x.y.z.k has not responded in 120 seconds. Reconnecting... Server's smb.conf: [global] unix extensions = yes case sensitive = auto delete readonly = yes

On 24/05/2019 10:18, sambalist--- via samba wrote: > I've tried straight the IP into the share \\x.y.z.k\, same behaviour. > > The server is smbd 4.7.6 on Ubuntu 18.04. > The client is cifs-utils 6.8.2, samba-common 4.10.0 on Ubuntu 19.04 > > What i get on dmesg is > [ 1395.187394] CIFS VFS: Server x.y.z.k has not responded in 120 > seconds. Reconnecting... > I

I think a network trace would tell us for use whether the server is responding or not. You can follow the instruction here to make one: https://wiki.samba.org/index.php/Bug_Reporting#cifs.ko -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah

Hi there! I have a very weird behavior in samba. I have been using a samba server for sharing a folder to a cifs mount client for many years. Since last update, everything still works fine, but when i open a photo subfolder with a specific software (gwenview) and try to load thumbnails, the whole mount stops responding. On the client, i have the "server not responding after 120

I am teaching a DTrace class and a student noticed that 2 iosnoop scripts run in two different windows were producing different results. I was not able to answer why this is. Can anyone explain this. Here are the reults from the two windows: # io.d ... sched 0 <none> 1024 dad1 W 0.156 bash 1998

Usually it means that the file changed while rsync was running. But it can also mean that a hardware problem (usually RAM) is causing the hashing to return bogus results. On 6/3/19 6:09 AM, sambalist--- via rsync wrote: > Hi there! > > On a daily backup script, I am getting a lot of these messages: > > WARNING: <filename> -- update retained (will try again). > >

Hi, I just had a try using the xeno-unstable. When I used the xc_dom_create.py to create a new domain I got the followings: ============================================== Traceback (most recent call last): File "/usr/bin/xc_dom_create.py", line 332, in ? (current_id, current_port) = make_domain() File "/usr/bin/xc_dom_create.py", line 238, in make_domain

hello, I wanna use some mathematics formula and to do this I tried several way in paricular using strsplit textconnection scan setdiff but I think that it's a lil hard the data frame that I'm working on is as follow > donCalcara2 Id_Cara Form_C 1 743

I would really like a little clarification for the error in the Subject. 1. If it says "update retained" and I'm doing an --inplace sync, does that mean it did copy over the blocks it found during the initial pass? In other words, can I assume the synced version on the receiving end looks just like the source at the time it was first scanned for changes? I hope so. 2. If #1 is

Hey Kevin! Once you start dropping under (I think) 32kbps, the codec naturally starts losing stereo separation for the benefit of quality. If you really want perfect stereo at 16kbps CBR (this is horrifically low in my opinion) you might be better off splitting the audio and encoding each part at 8kbps CBR. Or, there may be a magic "enforce 100% stereo" one could pass? (doesn't look

On Fri, Sep 02, 2016 at 10:52:05PM -0400, Fred Smith wrote: > I've recently had this problem on two C7 systems, wherein when doing "yum > update", I get a warning about /boot being low on space. > > both systems were installed using the partition size recommended by > Anaconda, right now "df -h" shows /boot as 494M, with 79M free. > > I don't

Mostly it means that the file rsync ended up with on the target end didn't match the file on the source it started with. This is mostly caused by the file being modified on the source while rsync is copying it but it can also be a memory corruption problem. On 8/11/20 1:13 PM, Peng Yu via rsync wrote: > Hi, > > I see some warnings like the following. Could anybody explains what

Hi, I see some warnings like the following. Could anybody explains what they mean? Thanks. 19/31274477.pdf 257,169,119 0% 1.26MB/s 0:03:15 (xfr#121, to-chk=848309/1043298)WARNING: 18/32281577.pdf failed verification -- update retained (will try again). WARNING: 19/28879866.pdf failed verification -- update retained (will try again). -- Regards, Peng

Hi Folks, This tip is probably lurking somewhere already, but I've just discovered it the hard way, so it is probably worth passing on for the benefit of those who might otherwise hack their way along the same path. Say (for example) you want to do a logistic regression of a binary response Y on variables X1, X2, X3, X4: GLM <- glm(Y ~ X1 + X2 + X3 + X4) Say there are 1000 cases in the

Export initrd in debugfs when retained. As a side effect, initrd_start and initrd_end are not cleared when the initrd is retained. After this patch, one can then copy the initrd space from debugfs and pass it to kexec as the initrd, or do something else with it (maybe it was an initrd not an initramfs). Signed-off-by: Milton Miller <miltonm at bga.com> --- This is a lot more reliable

Hi Some time ago there was a discussion on the above subject. I have scanned the past few month's mailing list archives and cannot find the relevant mail(s). Could somebody please repost the solution or point me at the correct resource. I would also appreciate advice on how to do this on a RHEL4 server being updated with up2date. Is it safe just to delete the old kernel and initrd

I am learning the package "caret", after I do the "rfe" function, I get the error ,as follows: Error in `[.data.frame`(x, , retained, drop = FALSE) : undefined columns selected In addition: Warning message: In predict.lm(object, x) : prediction from a rank-deficient fit may be misleading I try to that manual example, that is good, my data is wrong. I do not know what

In current Crossbow''s implementation, vlan tag seems to be unconditionally retained for promisc mode listener even when MAC_OPEN_FLAGS_TAG_DISABLE is not specified. I saw comments in mac_rx_deliver() saying that this is deliberately designed like this. I''m wondering why we design it like this (choose not to respect MAC_OPEN_FLAGS_TAG_DISABLE flag for promisc mode listener)? Or

Hello, I've been using Opus on an STM32 M4 platform for speech coding in mono mode. I thought I'd try stereo for grins to see if I can handle the CPU load, and I'm getting a return code of -1 from opus_decode_float (using CBR and 40ms frames). I decided to try the opusenc and opusdec tools to just see how the command line apps would behave. I am getting decoded audio, but I am