SMB should explicitly fail deletion of mountpoints
Customer unexpectedly deleted a sub-mount in a (hierarchical) SMB share, e.g.
zfs dataset share path
The customer (accidently) renamed foo/bar to foo/baz which appeared to work,
but actually ended up copying all the data from foo/bar (in the dataset data/foo/bar)
to a new directory foo/baz (in the dataset data/foo), causing a bunch o' problems.
Updated by Gordon Ross about 1 year ago
From Matt Barden:
This appears to be a consequence of Windows Client behavior. After testing this and capturing the event with wireshark and dtrace, I discovered that when attempting to move one mountpoint into another mountpoint, the filesystem correctly rejects the attempt with EXDEV ("cross-device link"). SMB returns this error to the client (NT_STATUS_NOT_SAME_DEVICE). Upon receiving this error, the Windows Client then proceeds to copy over all of the data from the source to the target, and then deletes the source.
SMB should correctly inform the client that removing a mount point is not going to be allowed.
Updated by Electric Monk 12 months ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit 06721c885c2d7becabe2cba874b84cdfba66eb47 Author: Matt Barden <email@example.com> Date: 2019-11-14T14:23:07.000Z 11852 SMB should explicitly fail deletion of mountpoints Reviewed by: Gordon Ross <firstname.lastname@example.org> Reviewed by: Evan Layton <email@example.com> Reviewed by: Andrew Stormont <firstname.lastname@example.org> Approved by: Garrett D'Amore <email@example.com>