What privileges are needed to delete a read-only btrfs subvolume

This answer works on Debian (tested on lenny and squeeze). After investigation, it seems to work only thanks to a Debian patch; users of other distributions such as Ubuntu may be out of luck.

You can use mount --bind. Mount the “real” filesystem under a directory that's not publicly accessible. Make a read-only bind mount that's more widely accessible. Make a read-write bind mount for the part you want to expose with read-write access.

mkdir /media/hidden /media/hidden/sdz99
chmod 700 /media/hidden
mount /dev/sdz99 /media/hidden/sdz99
mount -o bind,ro /media/hidden/sdz99/world-readable /media/world-readable
mount -o bind /media/hidden/sdz99/world-writable /media/world-writable

In your use case, I think you can do:

mkdir /var/smb/hidden
mv /var/smb/snapshot /var/smb/hidden
mkdir /var/smb/snapshot
chmod 700 /var/smb/hidden
chmod 755 /var/smb/hidden/snapshot
mount -o bind,ro /var/smb/hidden/snapshot /var/smb/hidden/snapshot

I.e. put the real snapshot directory under a restricted directory, but give snapshot read permissions for everyone. It won't be directly accessible because its parent has restricted access. Bind-mount it read-only in an accessible location, so that everyone can read it through that path.

(Read-only bind mounts only became possible several years after bind mounts were introduced, so you might remember a time when they didn't work. I don't know offhand since when they work, but they already worked in Debian lenny (i.e. now oldstable).)

A snapshot (in this sense) is a part of the filesystem. In btrfs terminology, it's a subvolume — it's one of the directory trees on the volume. It isn't in “archive form”. Making a snapshot of a subvolume creates a new subvolume which contains the data of the original volume at the date the snapshot was made. Subsequent writes to the original subvolume don't affect the snapshot and vice versa. All subvolumes are part of the same volume — they designate subsets (potentially overlapping) of the data in the volume.

The parts of the snapshot that haven't been modified in either subvolume share their storage. Creating a snapshot initially requires no storage except for the snapshot control data; the amount of storage increases over time as the content of the subvolumes diverge.

The most important property of snapshot creation is that it's atomic: it takes a picture of the data at a point in time. This is useful to make backups: if the backup program copies files from the live system, it might interact poorly with modifications to the files. For example, if a file is moved from directory A to directory B, but the backup program traversed B before the move and A after the move, the file wouldn't be included in the backup. Snapshots solve this problem: the file will be in A if the snapshot is made before the move and in B if it's made after, but either way it will be there. Then the backup program can copy from the snapshot to the external media.

Since the snapshot is on the same volume as the original, it's stored in the same way, e.g. it's encrypted if the volume is encrypted.

A snapshot reproduces the original directory tree, including permissions and all other metadata. So the permissions are the same as the original. In addition, users must be able to access the snapshot directory itself. If you don't want users to be able to access a snapshot at all, create it under a directory that they can't access (you can place the snapshot anywhere you want).

If you want to make a copy of the snapshot outside the filesystem, access or mount the snapshot then make a copy with your favorite program (cp, rsync, etc.). You can find sample commands in the btrfs wiki; see the manual page for a full reference.