[Samba] Server side copy not working? (different shares)

Soukyuu · 2014-07-24 23:23:29

So according to this, server side copy should be enabled by default and win8+ clients should be able to take advantage of it.
Well, on my setup, they don't. I have just copied a file from share_a to share_b on a windows 8.1 and it diligently copied 5gb of data to my pc before copying it back to share_b. -_-

Since the setup is supposed to work per default, I'm not sure which info I am supposed to provide. I work with big files on separate shares quite frequently. Please don't tell me I have to go back to windows for this to work again?

Last edited by Soukyuu (2014-07-25 17:49:00)

Rexilion · 2014-07-25 05:25:16

How are you accessing the share? I think that if you use GVFS, then it probably won't work.

Soukyuu · 2014-07-25 11:15:43

Sorry, I guess I shouldn't have posted it before going to sleep.
The setup is currently as follows:
- 1x linux server (arch) serving 4x windows 8.1 PCs
- each PC has one user
- each user has their documents etc folders mapped to server shares
- some shares are also mounted using the "create network link"

So, the shares are accessed via native windows interfaces, whatever the name is. Only the server is running linux (and samba). Moving files within, say, downloads folder works, moving from downloads to videos causes a fallback to "traditional file copy".

alphaniner · 2014-07-25 13:53:09

Maybe relevant:

The page you linked wrote:

Both source and destination files must reside on the same Samba share!

Soukyuu · 2014-07-25 14:40:49

That's... disappointing to say the least. Why would they restrict it that way? It doesn't make any sense to me.

alphaniner · 2014-07-25 15:17:47

I doubt it's an arbitrary restriction. Maybe try the samba mailing lists.

Soukyuu · 2014-07-25 17:48:28

I actually just took two of my windows 8.1 PCs and simulated the scenario above. While there is no (significant) network traffic moving files from one share to another, it isn't instant. The time it takes is more or less the same, the difference can be attributed to different disk speeds I guess. So it looks like windows is no different w.r.t. this limitation. I guess I remembered it wrong.

I could imagine it has to do with the fact the client doesn't know if the two shares are on the same disk, so it takes the safer route of copying -> deleting the files instead of moving the file (or rather, has no means to instruct the server to move the file). If I was designing this, I'd just let the server decide what is appropriate. Cause the server can check if file are on the same device, obviously... I wonder why they didn't implement this in the first place. Oh well, it's solved I guess? Or should I mark it something like "no solution"?

alphaniner · 2014-07-25 18:40:51

If there was no significant network traffic and the size of the file was significant, then I would conclude it was a server-side copy. You can get an idea of how much data was transfered over the network by looking at the 'Status' of the interface in Windows, or /sys/class/net/<device>/statistics/[tr]x_bytes in Linux.

Maybe server-side move isn't actually supported, so a copy-delete is done intead. If so, a server-side 'move' could be [temporally] indistinguishable from a client-side copy/move on an uncongested gigabit network.

Last edited by alphaniner (2014-07-25 18:44:20)

Soukyuu · 2014-07-25 19:32:02

Server side move works, as long as we're inside the same share, so it is supported. I'll try to sum it up, client is always win8.1, server is either win8.1 (=windows) or arch (=linux)

share_a/folder_a -> share_a/folder_b:
copy      windows linux
network      n      n
time        1:56  2:04

move      windows linux
network      n      n
time        0:00  0:00

This behaves as expected. However,

share_a -> share_b:
copy      windows linux
network      n      y
time        1:56  2:04

move      windows linux
network      n      y
time        1:56  2:04

This does not. When the server is linux-based, there is network traffic in both directions, so the files are being buffered locally. Also, no matter if it's windows or linux server-side, the move is not instant, but behaves more like a copy. Except that, again, linux-server causes the files to be buffered client side, while windows makes a server side copy -> delete old file, it seems.

So not even the "native" implementation is working as I'd expect it to.

Arch Linux

#1 2014-07-24 23:23:29

[Samba] Server side copy not working? (different shares)

#2 2014-07-25 05:25:16

Re: [Samba] Server side copy not working? (different shares)

#3 2014-07-25 11:15:43

Re: [Samba] Server side copy not working? (different shares)

#4 2014-07-25 13:53:09

Re: [Samba] Server side copy not working? (different shares)

#5 2014-07-25 14:40:49

Re: [Samba] Server side copy not working? (different shares)

#6 2014-07-25 15:17:47

Re: [Samba] Server side copy not working? (different shares)

#7 2014-07-25 17:48:28

Re: [Samba] Server side copy not working? (different shares)

#8 2014-07-25 18:40:51

Re: [Samba] Server side copy not working? (different shares)

#9 2014-07-25 19:32:02

Re: [Samba] Server side copy not working? (different shares)

Board footer