Updated binaries are incompatible with btrfs

[markdumay]

Updated binaries are incompatible with btrfs

[markdumay]

That's unfortunate. My NAS still uses EXT4, so I'm not able to reproduce your error. However, after some research, possibly changing the storage driver might help? I used Docker's guide as a reference. Following step 6 of the guide, add "storage-driver": "btrfs" to /var/packages/Docker/etc/dockerd.json. Make a backup of the file first to revert back to the previous version in case of any errors. The full configuration could look something like this:

{
    "storage-driver": "btrfs",
    "data-root" : "/var/packages/Docker/target/docker",
    "log-driver" : "json-file",
    "registry-mirrors" : [],
    "group": "administrators"
}

You will have to restart the Docker service to pick up the changes. Revert back to the old version of dockerd.json if starting of the service fails.

synoservicectl --stop pkgctl-Docker
synoservicectl --start pkgctl-Docker

[photocyte]

Hi there,
Thanks for the great script! I ran into this same issue on a DS1819+ with a brtfs filesystem, where after updating Docker through the script, running docker pull would produce the Failed to create btrfs snapshot: inappropriate ioctl for device. error.

I found that editing /var/packages/Docker/etc/dockerd.json to use the vfs storage device instead of brtfs worked. The Docker documentation suggests that the vfs storage driver, while not performant nor recommended for production use, is robust/stable, so I feel OK using it. In a brief test the overlay2 storage driver didn't work for me, hence why I used vfs

In my case I also deleted all my existing images before re-pulling everything, since the storage driver has something to do with how the images are stored:

docker system prune
docker system prune -a

Final dockerd.json was as follows:

{
    "data-root" : "/var/packages/Docker/target/docker",
    "log-driver" : "json-file",
    "registry-mirrors" : [],
    "group": "administrators",
    "storage-driver" : "vfs"
}

After all that, the updated non-DSM Docker seems to be working well for me after re-pulling and re-configuring my images. That being said, the GUI for Docker in DSM has a few bugs: the days since reboot for each container is some very large value, and the logs are not viewable (presumably from json-file vs db).

[markdumay]

Impressive article @technorabilia! I was always a bit hesitant to bypass Docker's package completely and to install Docker from scratch instead. But it's great to know it can be done. If your suspicion is right, then Synology's flawed kernel support for btrfs is the core issue here.

I'll include a link to your article in the Known Issues, as it might help others too. Thanks for sharing your experience!

[frobnicaty]

I've found the code responsible for this. In the Synology kernel, linux-4.4.x.tar.gz, the following BTRFS code is patched, and throws ENOTTY (= "Inappropriate ioctl for this device").

I'm not familiar with BTRFS or kernel internals, but combined with patches in ./include/uapi/linux/btrfs.h, ./usr/include/linux/btrfs.h, the rest of ./fs/btrfs/, and /usr/local/include/synobtrfssnapusage/ in the toolkit image, my impression is that Synology patches btrfs in several ways, but particularly to restrict or modify btrfs snapshots, which are very heavily used by both Synology and Docker.

./fs/btrfs/ioctl.c

long btrfs_ioctl(struct file *file, unsigned int
		cmd, unsigned long arg)
{
	struct btrfs_root *root = BTRFS_I(file_inode(file))->root;
	void __user *argp = (void __user *)arg;

	switch (cmd) {
	case FS_IOC_GETFLAGS:
		return btrfs_ioctl_getflags(file, argp);
	case FS_IOC_SETFLAGS:
		return btrfs_ioctl_setflags(file, argp);
	case FS_IOC_GETVERSION:
		return btrfs_ioctl_getversion(file, argp);
	case FITRIM:
		return btrfs_ioctl_fitrim(file, argp);
	case BTRFS_IOC_SNAP_CREATE:
		return btrfs_ioctl_snap_create(file, argp, 0);
	case BTRFS_IOC_SNAP_CREATE_V2:
		return btrfs_ioctl_snap_create_v2(file, argp, 0);
	case BTRFS_IOC_SUBVOL_CREATE:
		return btrfs_ioctl_snap_create(file, argp, 1);
	case BTRFS_IOC_SUBVOL_CREATE_V2:
		return btrfs_ioctl_snap_create_v2(file, argp, 1);
	case BTRFS_IOC_SNAP_DESTROY:
		return btrfs_ioctl_snap_destroy(file, argp);
	case BTRFS_IOC_SUBVOL_GETFLAGS:
		return btrfs_ioctl_subvol_getflags(file, argp);
	case BTRFS_IOC_SUBVOL_SETFLAGS:
		return btrfs_ioctl_subvol_setflags(file, argp);
#ifdef MY_ABC_HERE
	case BTRFS_IOC_SUBVOL_GETINFO:
		return btrfs_ioctl_subvol_getinfo(file, argp);
#endif
	case BTRFS_IOC_DEFAULT_SUBVOL:
		return btrfs_ioctl_default_subvol(file, argp);
	case BTRFS_IOC_DEFRAG:
		return btrfs_ioctl_defrag(file, NULL);
	case BTRFS_IOC_DEFRAG_RANGE:
		return btrfs_ioctl_defrag(file, argp);
	case BTRFS_IOC_RESIZE:
		return btrfs_ioctl_resize(file, argp);
	case BTRFS_IOC_ADD_DEV:
		return btrfs_ioctl_add_dev(root, argp);
	case BTRFS_IOC_RM_DEV:
		return btrfs_ioctl_rm_dev(file, argp);
	case BTRFS_IOC_FS_INFO:
		return btrfs_ioctl_fs_info(root, argp);
	case BTRFS_IOC_DEV_INFO:
		return btrfs_ioctl_dev_info(root, argp);
	case BTRFS_IOC_BALANCE:
		return btrfs_ioctl_balance(file, NULL);
	case BTRFS_IOC_TRANS_START:
		return btrfs_ioctl_trans_start(file);
	case BTRFS_IOC_TRANS_END:
		return btrfs_ioctl_trans_end(file);
	case BTRFS_IOC_TREE_SEARCH:
		return btrfs_ioctl_tree_search(file, argp);
	case BTRFS_IOC_TREE_SEARCH_V2:
		return btrfs_ioctl_tree_search_v2(file, argp);
	case BTRFS_IOC_INO_LOOKUP:
		return btrfs_ioctl_ino_lookup(file, argp);
	case BTRFS_IOC_INO_PATHS:
		return btrfs_ioctl_ino_to_path(root, argp);
	case BTRFS_IOC_LOGICAL_INO:
		return btrfs_ioctl_logical_to_ino(root, argp);
	case BTRFS_IOC_SPACE_INFO:
		return btrfs_ioctl_space_info(root, argp);
#ifdef MY_ABC_HERE
	case BTRFS_IOC_SYNC_SYNO:
#endif
	case BTRFS_IOC_SYNC: {
		int ret;

#ifdef MY_ABC_HERE
		if (cmd == BTRFS_IOC_SYNC_SYNO) {
			goto skip_start_delalloc;
		}
#endif
		ret = btrfs_start_delalloc_roots(root->fs_info, 0, -1);
		if (ret)
			return ret;
#ifdef MY_ABC_HERE
skip_start_delalloc:
#endif
		ret = btrfs_sync_fs(file_inode(file)->i_sb, 1);

		wake_up_process(root->fs_info->transaction_kthread);
		return ret;
	}
	case BTRFS_IOC_START_SYNC:
		return btrfs_ioctl_start_sync(root, argp);
	case BTRFS_IOC_WAIT_SYNC:
		return btrfs_ioctl_wait_sync(root, argp);
	case BTRFS_IOC_SCRUB:
		return btrfs_ioctl_scrub(file, argp);
	case BTRFS_IOC_SCRUB_CANCEL:
		return btrfs_ioctl_scrub_cancel(root, argp);
	case BTRFS_IOC_SCRUB_PROGRESS:
		return btrfs_ioctl_scrub_progress(root, argp);
	case BTRFS_IOC_BALANCE_V2:
		return btrfs_ioctl_balance(file, argp);
	case BTRFS_IOC_BALANCE_CTL:
		return btrfs_ioctl_balance_ctl(root, arg);
	case BTRFS_IOC_BALANCE_PROGRESS:
		return btrfs_ioctl_balance_progress(root, argp);
	case BTRFS_IOC_SET_RECEIVED_SUBVOL:
		return btrfs_ioctl_set_received_subvol(file, argp);
#ifdef CONFIG_64BIT
	case BTRFS_IOC_SET_RECEIVED_SUBVOL_32:
		return btrfs_ioctl_set_received_subvol_32(file, argp);
#endif
	case BTRFS_IOC_SEND:
		return btrfs_ioctl_send(file, argp);
	case BTRFS_IOC_GET_DEV_STATS:
		return btrfs_ioctl_get_dev_stats(root, argp);
	case BTRFS_IOC_QUOTA_CTL:
		return btrfs_ioctl_quota_ctl(file, argp);
	case BTRFS_IOC_QGROUP_ASSIGN:
		return btrfs_ioctl_qgroup_assign(file, argp);
	case BTRFS_IOC_QGROUP_CREATE:
		return btrfs_ioctl_qgroup_create(file, argp);
	case BTRFS_IOC_QGROUP_LIMIT:
		return btrfs_ioctl_qgroup_limit(file, argp);
	case BTRFS_IOC_QUOTA_RESCAN:
		return btrfs_ioctl_quota_rescan(file, argp);
	case BTRFS_IOC_QUOTA_RESCAN_STATUS:
		return btrfs_ioctl_quota_rescan_status(file, argp);
	case BTRFS_IOC_QUOTA_RESCAN_WAIT:
		return btrfs_ioctl_quota_rescan_wait(file, argp);
#ifdef MY_ABC_HERE
	case BTRFS_IOC_QGROUP_QUERY:
		return btrfs_ioctl_qgroup_query(file, argp);
#endif
	case BTRFS_IOC_DEV_REPLACE:
		return btrfs_ioctl_dev_replace(root, argp);
	case BTRFS_IOC_GET_FSLABEL:
		return btrfs_ioctl_get_fslabel(file, argp);
	case BTRFS_IOC_SET_FSLABEL:
		return btrfs_ioctl_set_fslabel(file, argp);
	case BTRFS_IOC_FILE_EXTENT_SAME:
		return btrfs_ioctl_file_extent_same(file, argp);
	case BTRFS_IOC_GET_SUPPORTED_FEATURES:
		return btrfs_ioctl_get_supported_features(argp);
	case BTRFS_IOC_GET_FEATURES:
		return btrfs_ioctl_get_features(file, argp);
	case BTRFS_IOC_SET_FEATURES:
		return btrfs_ioctl_set_features(file, argp);
#ifdef MY_ABC_HERE
	case BTRFS_IOC_COMPR_CTL:
		return btrfs_ioctl_compr_ctl(file, argp);
#endif
#ifdef MY_ABC_HERE
	case BTRFS_IOC_SNAPSHOT_SIZE_QUERY:
		return btrfs_ioctl_snapshot_size_query(file, argp);
#endif
#ifdef MY_ABC_HERE
	case BTRFS_IOC_SYNO_CLONE_RANGE_V2:
		return btrfs_ioctl_syno_clone_range_v2(file, argp);
#endif
	}

	return -ENOTTY;
}

#ifdef CONFIG_COMPAT
long btrfs_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
	switch (cmd) {
	case FS_IOC32_GETFLAGS:
		cmd = FS_IOC_GETFLAGS;
		break;
	case FS_IOC32_SETFLAGS:
		cmd = FS_IOC_SETFLAGS;
		break;
	case FS_IOC32_GETVERSION:
		cmd = FS_IOC_GETVERSION;
		break;
	default:
		return -ENOIOCTLCMD;
	}

	return btrfs_ioctl(file, cmd, (unsigned long) compat_ptr(arg));
}
#endif

./fs/btrfs/super.c

static long btrfs_control_ioctl(struct file *file, unsigned int cmd,
				unsigned long arg)
{
	struct btrfs_ioctl_vol_args *vol;
	struct btrfs_fs_devices *fs_devices;
	int ret = -ENOTTY;

	if (!capable(CAP_SYS_ADMIN))
		return -EPERM;

	vol = memdup_user((void __user *)arg, sizeof(*vol));
	if (IS_ERR(vol))
		return PTR_ERR(vol);

	switch (cmd) {
	case BTRFS_IOC_SCAN_DEV:
		ret = btrfs_scan_one_device(vol->name, FMODE_READ,
					    &btrfs_fs_type, &fs_devices);
		break;
	case BTRFS_IOC_DEVICES_READY:
		ret = btrfs_scan_one_device(vol->name, FMODE_READ,
					    &btrfs_fs_type, &fs_devices);
		if (ret)
			break;
		ret = !(fs_devices->num_devices == fs_devices->total_devices);
		break;
	case BTRFS_IOC_GET_SUPPORTED_FEATURES:
		ret = btrfs_ioctl_get_supported_features((void __user*)arg);
		break;
	}

	kfree(vol);
	return ret;
}

I have compiled btrfs-progs v4.4 through v4.16 on e2fs v1.43.9, and v4.16.1 through v5.15 on current e2fs. All have the same error.

I am still working on compiling btrfs-progs v4.0 through v4.3.1. They require kernel headers to compile, which is a bit of a pain. (No rule to make target 'kernel-shared/volumes.h', needed by 'btrfs.o'.) TBD.

I suspect that, because v4.0-v4.3.1 of btrfs-progs rely on kernel headers, they thereby import Synology's btrfs related patches in the kernel, and that is what actually allows them to work. I haven't yet tried copying a non-Synology-sourced btrfs-progs v4.0 (e.g. compiled against the standard linux 4.4.180 headers) to see if it works on Synology.

If a normal btrfs-progs v4.0 works, then the issue is some sort of change in btrfs-progs between v4.0 and v4.4. If it doesn't, then the issue is the Synology patches to btrfs. I believe I could get the v4.0 btrfs-progs library compiled against the Synology kernel, but if the issue is Synology patches, I have no idea what versions of btrfs would be compatible even if v4.4+ could be coerced to use them for compilation.

For that matter, btrfs itself requires e2fs-progs, and Synology has patches to that, too. It's possible that that has some sort of lingering effect, even on non-ext2/3/4 filesystem. No idea.

Testing against standard v4.0 btrfs-progs, and non-Synology-e2fs Synology-kerenel-btrfs compiled v4.0 progs, should give an answer to most of it. If it is actually because btrfs-progs v4.0-v4.3.1 accidentally includes the Synology btrfs kernel patches, rather than because of some intentional change by btrfs-progs, that'll be a lot harder to test safely.

[worldofgeese]

Apologies it's been busy with work. Hope to get to this this weekend if not earlier.

…

On October 28, 2020 6:38:28 AM GMT+01:00, Mark Dumay ***@***.***> wrote: That's unfortunate. My NAS still uses EXT4, so I'm not able to reproduce your error. However, after some research, possibly changing the storage driver might help? I used Docker's [guide](https://docs.docker.com/storage/storagedriver/btrfs-driver/) as reference. Following step 6 of the guide, add `"storage-driver": "btrfs"` to `/var/packages/Docker/etc/dockerd.json`. Make a backup of the file first to revert back to the previous version in case of any errors. The full configuration could look something like this: ``` { "storage-driver": "btrfs", "data-root" : "/var/packages/Docker/target/docker", "log-driver" : "json-file", "registry-mirrors" : [], "group": "administrators" } ``` You will have to restart the Docker service to pick up the changes. Revert back to the old version of `dockerd.json` if starting of the service fails. ``` synoservicectl --stop pkgctl-Docker synoservicectl --start pkgctl-Docker ```

[Zenedith]

Hi,
Not working for me :(

[markdumay]

Sorry to hear that @Zenedith. Would you happen to have a backup of /var/packages/Docker/etc/dockerd.json that you could share? Perhaps Synology's original configuration (prior to running the update with synology-docker) gives some additional clues to what's happening.

[mietzen]

Hi, I haven't tried this script yet, but wanted to.
This is the content of cat /var/packages/Docker/etc/dockerd.json

{
   "data-root" : "/var/packages/Docker/target/docker",
   "log-driver" : "db",
   "registry-mirrors" : []
}

Info:

DS418play
DSM 6.2.3-25426 Update 2
Docker version 18.09.8, build 2c0a67b
SHR, btrfs

Edit:
That might be a hint:
https://together.jolla.com/question/92841/bug-btrfs-error-unable-get-label-inappropriate-ioctl-for-device/

The error is normal and happens because the version of btrfs-progs (that provides the "btrfs" command line tool) expects a more updated version of the btrfs kernel module (that in the Jolla kernel is pretty old).

Seems reasonable that a newer docker version is compiled against a newer version of the btrfs kernel module which is not present on the NAS.

[markdumay]

Hi @ngerke, the dockerd.json looks like a standard Synology configuration to me. You might be right about the requirement to have a newer btrfs kernel module present on the NAS. If that's the case, the only thing that comes to mind is to test the script with an older target version for Docker.

[Zenedith]

Hi, mine looks like this:

cat /var/packages/Docker/etc/dockerd.json
{
   "data-root" : "/var/packages/Docker/target/docker",
   "log-driver" : "db",
   "registry-mirrors" : [],
   "storage-driver" : "btrfs"
}

[markdumay]

hi @Zenedith, the syno_docker_update.sh script uses below configuration by default. Synology's db log driver is not supported and is replaced by json-file instead.

{
    "data-root" : "/var/packages/Docker/target/docker",
    "log-driver" : "json-file",
    "registry-mirrors" : [],
    "group": "administrators"
}

What happens if you manually update the dockerd.json file yourself? E.g.

{
    "data-root" : "/var/packages/Docker/target/docker",
    "log-driver" : "json-file",
    "registry-mirrors" : [],
    "group": "administrators",
    "storage-driver" : "btrfs"
}

What comes to mind is that syno_docker_update.sh is a bit too aggressive in replacing the entire dockerd.json file. Instead, it would be better if it modifies the log-driver configuration only. I'll create a new issue to address this. However, I'm still not sure if this will fix the Btrfs issue.

[markdumay]

Thanks for sharing @photocyte! This might be very helpful for others too. On a side note, the vfs storage driver is also how someone got Docker running on Apple silicon M1 apparently.

I'm considering to add a new flag to the script, supporting an alternative storage driver such as vfs. Some thoughts:

1. Add detection of the filesystem to detect_current_versions(), such as:

root_dir=$(docker info -f '{{ .DockerRootDir }}')
docker_fs=$(df "${root_dir}" --output=fstype | awk 'NR==2')

2. Terminate the script with an informative error in validate_current_version() when docker_fs is not equal to EXT?
3. Add a new flag --storage-driver to support alternative storage drivers such as vfs, also passing the check in step 2

Addressing issue #40 first would be a prerequisite.

That being said, the GUI for Docker in DSM has a few bugs: the days since reboot for each container is some very large value, and the logs are not viewable (presumably from json-file vs db).

Yes, unfortunately these are known issues. I haven't found a way to fix the incorrect time yet. Running docker ps from the command line works as expected though. I suspect you're right regarding the log driver too. Suggestions are welcome! ;-)

[1activegeek]

Thank you guys for this continued discussion and the solution using vfs driver. I was running into this very issue myself recently as I want the benefit of btrfs, but would like to operate on a newer Docker version as well. I wanted to report that I was successful with this method as well. I did have to simply stop and start the docker service through the Syno interface and was off to the races.

One thing I wanted to point out as a potential area to check/test out - custom networks. I ran into an issue and banged my head troubleshooting and hitting walls last night for about 2.5 hrs because my container would not get any internet connectivity. I finally decided after some sleep, to try reverting to the previous docker version - and voila the container could then get internet connectivity. Subsequently updated to the newer docker version, and the container still worked with the network that was created on the original docker version.

Bottom line - it seems there is an issue in Synology setup somewhere if you try to use the newer docker network commands to create a custom network. Might be something to check out - or maybe someone knows something more about the correlations and configurations of syno with docker.

[markdumay]

Thanks for sharing your findings @1activegeek. Regarding the network issues, are they related to user-defined bridge networks (#35)? I suspect the iptables configuration needs some additional tweaks on Synology for these kind of networks. In another repository I scripted some steps (see the function execute_create_macvlan() specifically), and added a static route among other things to get a macvlan network up and running.

Your approach to create the networks/containers by using the default (older) Synology Docker version might be a helpful workaround for now. I'm curious though, does it survive reboots?

[1activegeek]

Wow, yup you are correct. I must have been dense in my reading of that on the Known Issues. Sorry for that. Yes it would appear that is the issue I'm facing. I've just tested the reboot and it does look as though you are correct, it has lost it's connectivity. Will bring my finding to that issue to discuss.

So net/net - ignore my previous comment - and thanks for the workaround! 😄

[markdumay]

No problem, glad to hear it's working now! Looking forward to your additional findings.

[technorabilia]

Now Docker 20.10.3 is available as a package for DSM 6.2 (and DSM 7 RC), I thought we would be able to upgrade to the latest Docker version 20.10.7 more easily but unfortunately there is still the annoying inappropriate ioctl for device error message when you install the latest Docker binaries.

$ docker --version
Docker version 20.10.7, build f0df350
$ docker run hello-world
ERRO[2021-06-03T09:23:07.666225382+02:00] Handler for POST /v1.41/containers/create returned error: Failed to create btrfs snapshot: inappropriate ioctl for device
docker: Error response from daemon: Failed to create btrfs snapshot: inappropriate ioctl for device.
See 'docker run --help'.
$

[markdumay]

That's unfortunate @technorabilia. I doubt Synology addressed any of the core issues with their Docker package to be honest. btrfs is still a no go it seems.

Another approach suggested by Kristofer Lundgren (full article on Medium) is to use Docker-in-Docker instead. He also has an approach to work around the btrfs issue. In summary, you could create a new ext4 volume next to your current btrfs volume, and mount Docker onto the ext4 volume. I haven't tried this myself, but it might help you out.

[technorabilia]

Thanks @markdumay, I will have a look at the dind solution. I did try different storage drivers aufs, overlay2, btrfs and vfs with various results. Storage driver vfs does seem to work on btrfs as well, but of course you do not have the benefits of btrfs since vfs is not a union file system and there is no cow support. At least to my (limited) understanding.

You can find my findings on my blog. Please let me know if it is not appropriate to link to my blog here and I will remove the link.

[technorabilia]

I did some further research.

If I replace all the Synology docker binaries in /volume1/@appstore/Docker/usr/bin (version 20.10.3 from the latest Synology package) with the 20.10.7 ones, I get the inappropriate ioctl for device error message.

(in /var/packages/Docker/etc/dockerd.json, I also needed to replace the custom log-driver from db to json-file but that is another story...)

If I restore the dockerd binary (version 20.10.7) to the one from Synology (version 20.10.3) everything seems to be working again. So it looks like Synology made some changes to the dockerd source code to make it work?

I think the error message inappropriate ioctl for device error originates from this location.

I do know how to compile the dockerd source code. The question is: where do I find the changes that were made by Synology? I do know there is some source code available on SourceForge, but I could not find anything related.

Ideas anyone?

[markdumay]

I think you’re right - Synology seems to tweak many of its software components and Docker is no exception. I haven’t found the source code unfortunately. A good starting point could be xpenology.com, but I couldn’t find anything related to Docker over there either.

…

On 4 Jun 2021, at 16:51, Technorabilia ***@***.***> wrote:  I did some further research. If I replace all the Synology docker binaries in ***@***.***/Docker/usr/bin (version 20.10.3 from the latest Synology package) with the 20.10.7 ones, I get the inappropriate ioctl for device error message. (in /var/packages/Docker/etc/dockerd.json, I also needed to replace the custom log-driver from db to json-file but that is another story...) If I restore the dockerd binary (version 20.10.7) to the one from Synology (version 20.10.3) everything seems to be working again. So it looks like Synology made some changes to the dockerd source code to make it work? I think the error message inappropriate ioctl for device error originates from this location. I do know how to compile the dockerd source code. The question is: where do I find the changes that were made by Synology? I do know there is some source code available on SourceForge, but I could not find anything related. Ideas anyone? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[frobnicaty]

@technorabilia I had this issue. Just use Synology's shipped /usr/sbin/btrfs, which claims --version of btrfs-progs v4.0. (Entware opkg has btrfs-progs v5.11.)

Synology's btrfs is able to do this just fine, whereas the opkg one errors with Inappropriate ioctl for device.

I haven't tested any other versions.

$ which btrfs
/opt/bin/btrfs
$ btrfs --version
btrfs-progs v5.11
$ btrfs subvolume create test1
Create subvolume './test1'
$ btrfs subvolume snapshot test1 test2
Create a snapshot of 'test1' in './test2'
ERROR: cannot snapshot 'test1': Inappropriate ioctl for device
$ /usr/sbin/btrfs --version
btrfs-progs v4.0
$ /usr/sbin/btrfs subvolume snapshot test1 test2
Create a snapshot of 'test1' in './test2'
$ /usr/sbin/btrfs subvolume create test3
Create subvolume './test3'
$ /usr/sbin/btrfs subvolume snapshot test3 test4
Create a snapshot of 'test3' in './test4'

[frobnicaty]

Also, the kernel config is at https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/25426branch/ -> pick your CPU architecture (e.g. V1000) -> linux-4.4.x.txz -> synoconfigs/$archname. Gzip that and it's compatible with https://raw.githubusercontent.com/docker/docker/master/contrib/check-config.sh.

The correct "package architecture" is listed for each model at https://kb.synology.com/en-global/DSM/tutorial/What_kind_of_CPU_does_my_NAS_have

E.g. for V1000, I get:

$ ./check-config.sh synokernelconfig.gz
info: reading kernel config from synokernelconfig.gz ...
                                                                                                                                                                                           
Generally Necessary:
- cgroup hierarchy: properly mounted [/sys/fs/cgroup]
- apparmor: enabled and tools installed
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: enabled
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled (as module)
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: enabled (as module)
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: enabled (as module)
- CONFIG_NETFILTER_XT_MARK: enabled (as module)
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_POSIX_MQUEUE: enabled
- CONFIG_DEVPTS_MULTIPLE_INSTANCES: enabled
- CONFIG_NF_NAT_IPV4: enabled (as module)
- CONFIG_NF_NAT_NEEDED: enabled

Optional Features:
- CONFIG_USER_NS: missing

[1activegeek]

No sure if it voids the issues fully, but I believe it does - it would appear that Synology has now finally caught up with the current versions of Docker, which I believe also brought about proper support for btrfs. I had not long ago updated my docker packages to the Sync versions, and I had Zero issues. Not sure if it's because I had already had fixes in place, but it may be more worth trying the official Sync Docker updates now.

[markdumay]

Thanks for sharing @frobnicaty, I have updated the known issues (#42) accordingly.

[markdumay]

I agree with @1activegeek, it would be best if we would not have to use this custom update script at all. I am running DSM 7 on my NAS for a while now. Unfortunately, I still encountered issues with Docker stack deployments using Synology's Docker package. I did not investigate thoroughly though.

[1activegeek]

I agree with @1activegeek, it would be best if we would not have to use this custom update script at all. I am running DSM 7 on my NAS for a while now. Unfortunately, I still encountered issues with Docker stack deployments using Synology's Docker package. I did not investigate thoroughly though.

I'll have to take a peak when I get back on my docker stack on the DSM and see if it's because I already had mitigating changes in place from the work here or not. I didn't migrate to DSM 7 yet, as I want to let them bake that a bit more and close a few of the gaps they still have from the older DSM version. I'm sure in that migration I'll definitely feel the pain if it's still there as you mention.

I was mostly excited just to see that they finally brought the current version up to par, not something like 3 revisions behind latest 😆

[markdumay]

Thanks for sharing your findings @frobnicaty - that's some serious research! Looking forward to your continued investigation.

[adn77]

I don't know if this is any help to your original issue - for running the backup solution Urbackup in docker on DSM7 I have been successfully using the btrfs binary supplied with DSM7 by mounting it into the container.