Bug 13599 - can't rename file or directory on Windows Server 2016 share
Summary: can't rename file or directory on Windows Server 2016 share
Status: RESOLVED DUPLICATE of bug 14169
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: 4.8.4
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2018-09-01 18:24 UTC by Jérémy Viès
Modified: 2020-12-19 16:47 UTC (History)
2 users (show)

See Also:

Failed renaming via gvfs mount (71.03 KB, application/x-pcapng)
2019-07-16 15:12 UTC, Nec
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jérémy Viès 2018-09-01 18:24:43 UTC

I reported an issue at gvfs (
https://gitlab.gnome.org/GNOME/gvfs/issues/19) that finally was due to
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
\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 :

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.

Jérémy Viès
Comment 1 Alexandre Massiot 2019-01-28 09:39:29 UTC

I am having the same exact issue, with a very similar configuration.
I also did try using Smbd 4.9.4-Debian, same issue.

Alexandre Massiot.
Comment 2 Nec 2019-02-12 14:57:21 UTC

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?
Comment 3 Nec 2019-07-10 15:05:08 UTC

I'd be glad to have a look at this point, but could anyone point me in the right direction (code tree, hints)?
Comment 4 Jeremy Allison 2019-07-10 16:35:39 UTC
Can you upload the wireshark traces and the debug level 10 logs from the smbclient reproducer please ?


Comment 5 Nec 2019-07-16 15:12:47 UTC
Created attachment 15310 [details]
Failed renaming via gvfs mount


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.


Comment 6 Nec 2019-09-03 11:45:22 UTC

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 :
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.
Comment 7 Schorschii 2020-06-22 08:37:47 UTC

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.

Comment 8 Schorschii 2020-07-04 14:03:36 UTC
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.
Comment 9 Björn Jacke 2020-07-10 12:33:45 UTC
duplicate of bug 14169 ?
Comment 10 Björn Jacke 2020-12-19 16:47:52 UTC

*** This bug has been marked as a duplicate of bug 14169 ***