Hi, I reported an issue at gvfs ( https://gitlab.gnome.org/GNOME/gvfs/issues/19) that finally was due to smbclient. The issue is about the fact I can't rename a file on a Windows Server 2016 share from nautilus. I've successfully reproduced the issue using smbclient itself. Here are the traces: smb: \xxx\yyy> rename text.txt toto.txt NT_STATUS_OBJECT_PATH_NOT_FOUND renaming files \server\share\xxx\yyy\text.txt -> \server\share\xxx\yyy\toto.txt smb: \xxx\yyy> The problem was observed using Samba 4.8.4 (debian package : 2:4.8.4+dfsg-2) Ondrej Holy from GVFS did not reproduced the issue, using Samba 4.9. If you need more information, I can try to run it again with more verbose or in debug. Regards, Jérémy Viès
Hi, I am having the same exact issue, with a very similar configuration. I also did try using Smbd 4.9.4-Debian, same issue. Regards, Alexandre Massiot.
Hello, I have the exact same issue. * Observed on CentOS server 7.6 and samba 4.7.1-9 from Ubuntu 18.10 with gvfs 1.38.0-2 . * Tried on shares with and without dollar sign in the share name. * Tried via nemo/thunar/libreoffice/smbclient/command line via /run/user/xxxx/gvfs Who could be the correct dev that could have a look at it or lead us towards the right direction?
Hello, I'd be glad to have a look at this point, but could anyone point me in the right direction (code tree, hints)?
Can you upload the wireshark traces and the debug level 10 logs from the smbclient reproducer please ? Thanks, Jeremy.
Created attachment 15310 [details] Failed renaming via gvfs mount Hello, I can not easily change the log level as the server is in production. But the trace I'm providing here is a case directly related to this bug : - My host is Xubuntu 19.04 with smbclient 4.10.0, gvfs-* 1.40.1-1 - I'm using nemo file manager, but that is only used to mount the samba share via gvfs - I create a directory : it's working - I'm trying to rename it : it's failing I'm providing the wireshard record of this rename failure, and I'm sure that this is the issue to be fixed. If needed, I'll make my best to raise the samba server log level and provide it too. Regards, Nicolas
Hello, Here is an update, I noticed a point that seems to be key in this bug. I have to precise our setup before the key information, wait for it. When I'm facing this bug, here is my setup (our company setup) : - We have a dozen of Linux Samba file servers, providing directory shares. - We have 3 windows namespace DFS servers which provide a common DFS hierarchy that points to the Samba shares. (zero replication involved - DFS only to provide a directory hierarchy). So far, nothing weird. - That gives us a unique share like : \\dfsroot\company and the sub-(virtual)-directories point to the different Samba shares (\\linux01\myShare...) - I usually access this unique share from my Ubuntu like any other windows client, mounting \\dfsroot\company and the DFS resolution is working fine. I can usually browse, create, modify, delete things. Until I hit this bug, that I can reproduce with LibreOffice, Nemo, and even the basic smbclient or the gvfs fuse mount point. I can not rename neither save a changed file. The update is that today I tried to access a Samba share directly and not through the DFS setup : \\linux01\myShare Doing so, I noticed the bug couldn't be reproduced. I'm hoping someone will lead me to the next debug step in order to fix this bug.
Hello, we're currently testing Linux clients as replacements for some Windows machines in our company and I'm facing the same issue with our file server. I would like to provide debug information. Please tell me which logs are relevant and which I should contribute. When connecting with option "client max protocol = NT1" renaming works. But then I can't copy files to the share using the Nemo file explorer. All other options for "client max protocol" will lead into the renaming issue. Regards Georg
To anyone using Netapp, this was the solution for our environment: https://github.com/nextcloud/server/issues/11295#issuecomment-644873704 In ONTAP System Manager, you have to set the "Symbolic Link" option to "Symlinks" for each share, then this renaming issue does not appear.
duplicate of bug 14169 ?
*** This bug has been marked as a duplicate of bug 14169 ***