Moving, samba, and partitions

So... I've narrowed this down, and it's really annoying.

I have a Samba share mounted on my PC. The samba share is backed by ZFS ... and ZFS done correctly uses lots of partitions. Windows sees it as one drive letter, but on the UN*X side, it's many partitions.

When I go to rearrange files, I'm almost always moving them between partitions. Now with DO, copy then delete works.... so the code is really simple: when move fails, fallback to copy-delete.

I assume this is relating to your post from 2016?

Did you ever send the Process Monitor log that Leo asked for ?

I vaguely remember that post, but I understand the problem better now.

It works when the folders are on the same partition. It fails when the folders are between partitions. Since I've narrowed it down to move vs. copy and partition vs. not, I figured you'd have all the info you required to track it down.

UAC elevator need not even be involved, since my user owns everything we're talking about.

Since you just might stall on my request even though I've probably solved it for you, here's the file you were after. Too big to email.

BTW... I like how you're not pushing a cloud service. I like my own cloud ... which isn't even owncloud.

BTW... supporting WEBDAV would be a good way to show support for people's own storage solutions.

Not yet. Setting up the same thing with standard Windows shares works without issue.

Samba or ZFS must not be responding in the normal way when we query the paths to ask if they are both on the same partition.

We definitely need the log to work out what Samba/ZFS is doing here, so thank you for finally sending it!

Which files/folders were you moving which failed? The log has 3.5 million entries, so I need to know what to filter on to find the relevant information.

Man... was just a random move.

I think I was moving a directory called "The.Blacklist.S07E06.720p.HDTV.x264-AVS" from X:\torrent\new\Video to X;\tmp\

... but it was also the only thing I asked dopus to due while running the trace.

BTW... You're welcome to get a login on my fileserver. At this point it's Samba 4.8.12 ... quite a bit newer than when we started this conversation.

Thanks for the extra info.

I've dug into how this works with Windows file servers, and the problem is Samba will not correctly report if something is a link/junction/etc. like a Windows file server does. This means we cannot tell that the folder is really something which points to another drive.

More technically:

  • We use ask for the folder's attributes and check for FILE_ATTRIBUTE_REPARSE_POINT to know if it's a link/junction.

    From looking at the Samba source, it looks like it can return that attribute sometimes but I'm not sure exactly when. It may depend on how the underlying filesystem reports things. But, looking at your logs, the attribute is never returned when Opus asks your Samba/ZFS server about the source or destination directories.

    (Checking my own logs, with a Windows server and a junction at the other end, I can see the attribute coming through fine, as well as several others that Samba isn't reporting. Samba in your logs only reports FILE_ATTRIBUTE_DIRECTORY for each dir and nothing else.)

  • If that attribute is set, then we would request the link/junction's target path using FSCTL_GET_REPARSE_POINT.

You can see here the only use of that IOCTL in the server-side Samba source that I can find:

        /* Fail it with STATUS_NOT_A_REPARSE_POINT */
        DEBUG(10, ("FSCTL_GET_REPARSE_POINT: called on %s. "
                   "Status: NOT_IMPLEMENTED\n", fsp_fnum_dbg(fsp)));

I also found this email from 2013 which says they weren't planning on implementing FSCTL_GET_REPARSE_POINT (although that may be out of date, it looks like it's still true in the current source code).

Working around the lack of FSCTL_GET_REPARSE_POINT would be possible, if we just assumed anything with FILE_ATTRIBUTE_REPARSE_POINT on it was on a different drive (maybe as an advanced option, since it would slow down moves between links that are on the same drives), but with both pieces of information missing, we'd have to assume every folder was a different drive, and make all moves slow.

So it does not look like Samba supports the two Windows/SMB APIs which we use to test if two folders are on the same drive.

If this works in Explorer, it may be trying the move via rename and then falling back on a copy-then-delete after that fails. The problem with that, as least how our code is structured, is it would not report progress properly while the file was being removed, since we need to know in advance which method we'll be using.

We need to think on this and discuss it further within the team. We could refactor a lot of the copy code to deal with this, but given this is a very niche thing which I don't think has been brought up by anyone else ever, I'm not sure that makes sense, since it involves changes to such a complex and fundamental piece of code (the copy code is very complex, for all the situations it deals with, including things like archives and FTP, and breaking file copying can be catastrophic, of course).

From our point of view, it's a shortcoming of Samba, since it should be able to report the real paths to things, or at least report that they are links and not normal directories. I'm surprised using that kind of ZFS link via Samba doesn't cause problems with more Windows software than just Opus.

1 Like

Well... if I may be so bold, some people may see it an ignore it. ... but the usage of ZFS/Samba as a storage solution is likely on the rise. FreeNAS ebodies this... and is quite a popular install. I believe, since this is a samba rather than ZFS problem, that you're going to see this in all the linux-based appliances, too.

I suppose I could poke at NFS again. I do prefer NFS... I'm just not keen on the pile of things I need to do to get it fully functional (ie: kerb/domain/ldap fubararrry (keeping it G rated)).

Thank-you for a real (ie: not just marketing) response.

Just for the heck of it, I tried moving it between two drive letters that point to different points on the same share. Ie: map x: to \vr\vr1 and map y: to \vr\vr1. This appears to work. I suppose that's less work than NFSv4 et. al.

NAS using Samba are common but I don't know how common it is to create links between paritions on them. Or multiple partitions at all, for that matter. Most NAS turn all the drives into a single RAID partition.

If you're using multiple partitions with Samba, it's best to make a separate share out of each one, instead of creating links between them on a single share.

Well... almost my point. That was the way they used to do it. ZFS encourages creating filesystems for each and everything. If you haven't read about ZFS and how it changes the game, you should. Start with wikipedia (not because their ZFS article is particularly good, but because wikipedia).

One of the ways that ZFS encourages creating many filesystems is that many ZFS features are per-filesystem. Snapshots, for instance. If you delete snapshots, you loose backup information... but sometimes you need to delete snapshots to reclaim space (reality sets in). If you have one big filesystem, you loose all that information for that whole filesystem. If you have filesystems per user or per project, you only loose that information w.r.t. that filesystem.

I suppose samba should propogate partition information. Interestingly, NFS does this by making you mount each partition. Leads to automounters and whatnot. Not perfect, either. ZFS is a big disruption that's totally worth it.

Then, if it's being used a lot with Samba, it should encourage Samba to support the bits of the SMB protocol they haven't bothered with yet. :slight_smile:

This is still an ongoing issue? I have the exact same issues with samba and moving files between partitions behind samba.

Is there a workaround?

The issue is/was with Samba not reporting when a folder is a link correctly. I don't know if Samba has improved since then, but it would also depend on the version of Samba used by your device, which is often out of date on many devices.

Well ... it is a bunch of a hack, but I've come to simply attach my main large share twice (as x:\ and y:) ... so that I can always force DO to think that it's a different drive.