Cannot Activate Drive D

[cliss]

I recently upgraded Synology devices and am trying to re-establish my previously-working setup. I had initially tried simply porting the prior container over, but that didn't work, so I'm starting anew.

I tried both the ubuntu18 branch, which I was using on my older Synology, as well as latest. Neither seem to work, and both seem to behave the same.

I cannot get Backblaze to activate the D: drive. I've confirmed the symbolic link looks right:

lrwxrwxrwx 1 app app  10 Sep 25 15:09 c: -> ../drive_c
lrwxrwxrwx 1 app app  10 Sep 25 15:15 com1 -> /dev/ttyS0
lrwxrwxrwx 1 app app  10 Sep 25 15:15 com2 -> /dev/ttyS1
lrwxrwxrwx 1 app app  10 Sep 25 15:15 com3 -> /dev/ttyS2
lrwxrwxrwx 1 app app  10 Sep 25 15:15 com4 -> /dev/ttyS3
lrwxrwxrwx 1 app app   9 Sep 25 15:14 d: -> /drive_d/
lrwxrwxrwx 1 app app   1 Sep 25 15:09 z: → /

I've used winecfg to set the drive as local:

I set my USER_ID and GROUP_ID to ones that match what my Synology expects, which I discovered using id, as described here. I am also executing using high privilege:

I can see the drives using the explorer:

I went digging through the Backblaze log files, and this is all I could come up with:

Log file contents

``` find . -type f -exec grep -H 'D:' {} \; ./bzdata/bzlogs/bztransmit/bztransmit25.log:20230925152012 0000000708 - WARNING: BzUiUtil::BzVolumesXml_QueryAttachDrives_UpdateBzVolXml - hGuid mis-match on drive D:\, myHguid=215702c1e7d2c4c388a10812, driveAssociatedHguid=45038730f664a5d275f20313 ./bzdata/bzlogs/bztransmit/bztransmit25.log:20230925152012 0000000708 - Connected and selected hard drive state: YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s0_v34538752606208 ./bzdata/bzlogs/bztransmit/bztransmit25.log:20230925152013 0000000812 - WARNING: BzUiUtil::BzVolumesXml_QueryAttachDrives_UpdateBzVolXml - hGuid mis-match on drive D:\, myHguid=215702c1e7d2c4c388a10812, driveAssociatedHguid=45038730f664a5d275f20313 ./bzdata/bzlogs/bztransmit/bztransmit25.log:20230925152016 0000000812 - Connected and selected hard drive state: YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s225582358_v34538752606208 ./bzdata/bzlogs/bztransmit/bztransmit25.log:20230925152026 0000000812 - WARNING: BzUiUtil::BzVolumesXml_QueryAttachDrives_UpdateBzVolXml - hGuid mis-match on drive D:\, myHguid=215702c1e7d2c4c388a10812, driveAssociatedHguid=45038730f664a5d275f20313 ./bzdata/bzlogs/bztransmit/bztransmit25.log:20230925152037 0000000812 - ATTEMPTING TO DECLARE VICTORY on initial upload processId=812 - about to ProduceTodoListOfFilesToBeBackedUp, ConnectedDrives: YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s225582358_v34538752606208 ./bzdata/bzlogs/bztransmit/bztransmit25.log:20230925152037 0000000812 - Connected and selected hard drive state: YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s225582358_v34538752606208 ./bzdata/bzlogs/bzbui/bzbui25.log:20230925152035 0000000648 - ERROR: BzUiUtil::BzVolumesXml_AssignNewBzVolumeGuidToVolume - BzFile::WriteVolumeGuidIntoDotBzVolDirOnVolume failed for volume D:\ with err: could_not_move_aside_prev_bzvol_id_file ./bzdata/bzlogs/bzbui/bzbui25.log:20230925152038 0000000648 - ERROR: BzUiUtil::BzVolumesXml_AssignNewBzVolumeGuidToVolume - BzFile::WriteVolumeGuidIntoDotBzVolDirOnVolume failed for volume D:\ with err: could_not_move_aside_prev_bzvol_id_file ./bzdata/bzlogs/bzbui/bzbui25.log:20230925152043 0000000648 - Setting newly selected drive: D:\, with VolumeGuid=v00117f7a6c0f260a6d074f90213 ./bzdata/bzlogs/bzbui/bzbui25.log:20230925152043 0000000648 - bzinfomanager.cpp:2443 [BzInfoManager::SetVolumesSelectedForBackup()]: Checking volume 1: mountPointPath "D:\", bzVolumeGuid "v00117f7a6c0f260a6d074f90213", bzAssociatedWithHostGuid "45038730f664a5d275f20313" ./bzdata/bzlogs/bzbui/bzbui25.log:20230925152043 0000000648 - Comparing VGUID:v000524218e6e8d2c4c280a40113 MountPoint: C:\ with v000524218e6e8d2c4c280a40113 MountPoint: C:\ ./bzdata/bzlogs/bzserv/bzserv25.log:20230925152006 0000000624 - ERROR: BzUiUtil::BzVolumesXml_AssignNewBzVolumeGuidToVolume - BzFile::WriteVolumeGuidIntoDotBzVolDirOnVolume failed for volume D:\ with err: could_not_move_aside_prev_bzvol_id_file ./bzdata/bzlogs/bzserv/bzserv25.log:20230925152006 0000000624 - ERROR: Could not assign BzVolumeId to D:\ ./bzdata/bzlogs/bzserv/bzserv25.log:20230925152006 0000000624 - WARNING: BzUiUtil::BzVolumesXml_QueryAttachDrives_UpdateBzVolXml - hGuid mis-match on drive D:\, myHguid=215702c1e7d2c4c388a10812, driveAssociatedHguid=45038730f664a5d275f20313 ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152007 0000000656 - PingDrivesThatAreSelectedForBackup: (processId=656) - before doing anything, todayDateTimeStr=20230925152007, driveReport=YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s0_v34538752606208 ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152010 0000000656 - PingDrivesThatAreSelectedForBackup: (processId=656) - after, signConnect=true, todayDateTimeStr=20230925152007, new_driveReport=YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s0_v34538752606208 ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152010 0000000656 - WARNING: BzUiUtil::BzVolumesXml_QueryAttachDrives_UpdateBzVolXml - hGuid mis-match on drive D:\, myHguid=215702c1e7d2c4c388a10812, driveAssociatedHguid=45038730f664a5d275f20313 ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152010 0000000656 - Connected and selected hard drive state (processId=656): YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s0_v34538752606208 ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152038 0000001772 - ERROR: BzUiUtil::BzVolumesXml_AssignNewBzVolumeGuidToVolume - BzFile::WriteVolumeGuidIntoDotBzVolDirOnVolume failed for volume D:\ with err: could_not_move_aside_prev_bzvol_id_file ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152038 0000001772 - FALSE: assign problem, probably could not write to: D:\ ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152043 0000001812 - ERROR: BzUiUtil::BzVolumesXml_AssignNewBzVolumeGuidToVolume - BzFile::WriteVolumeGuidIntoDotBzVolDirOnVolume failed for volume D:\ with err: could_not_move_aside_prev_bzvol_id_file ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152043 0000001812 - FALSE: assign problem, probably could not write to: D:\ ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152108 0000001840 - PingDrivesThatAreSelectedForBackup: (processId=1840) - before doing anything, todayDateTimeStr=20230925152108, driveReport=YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s225582358_v34538752606208 ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152111 0000001840 - PingDrivesThatAreSelectedForBackup: (processId=1840) - after, signConnect=true, todayDateTimeStr=20230925152108, new_driveReport=YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s225582358_v34538752606208 ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152309 0000001872 - PingDrivesThatAreSelectedForBackup: (processId=1872) - before doing anything, todayDateTimeStr=20230925152308, driveReport=YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s225582358_v34538752606208 ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152312 0000001872 - PingDrivesThatAreSelectedForBackup: (processId=1872) - after, signConnect=true, todayDateTimeStr=20230925152308, new_driveReport=YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s225582358_v34538752606208 ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152312 0000001872 - WARNING: BzUiUtil::BzVolumesXml_QueryAttachDrives_UpdateBzVolXml - hGuid mis-match on drive D:\, myHguid=215702c1e7d2c4c388a10812, driveAssociatedHguid=45038730f664a5d275f20313 ./bzdata/bzlogs/bzfilelist/bzfilelist25.log:20230925152312 0000001872 - Connected and selected hard drive state (processId=1872): YesBackedUp_con,gm,tZuZ,C:\__NotBackedUp_con,gm,tZuZ,D:\__con,gm,tZuZ,Z:\___abstr=no_1_s225582358_v34538752606208 ```

But no matter what I do, when I go into the Backblaze settings, and select the D: drive, it re-scans, but immediately disables the drive again:

I'm at a loss. Is there anything else I can try?

[JonathanTreffler]

I have a suspicion of how most of the issues, that people have with the docker happen, but I have not proven it so far, but maybe it helps you:

I think in order for Backblaze to properly work, drive_d has to be attached to a folder on the host, that does not contain any other folders, that are mounted there, only "real" subdirectories.

You can check this on the host with the findmnt command. There should be a mount somewhere up the directory tree, from where your directory on the host, which is mounted to drive d in the docker is, but no mounts down the directory tree.

So for example if your drive_d in the docker is /some/path/ on the host, findmnt should show one mount up the directory tree like /some/path/ or /some/, but none like /some/path/xyz/ .

It could additionally also be the case, that drive_d has to be a "real" subdirectory on the host. This would mean, that findmnt must show a directory up the directory tree as a mount, but not drive d itself. So /some/ as a mount would be OK, but /some/path/ not.

But again, this these are my current suspicions what differentiates the people for which the docker "just works" and for whom it does not and they could be completely wrong.

[cliss]

Thanks, @JonathanTreffler; that's very interesting.

I know you're not a Synology user, but a couple things are at play here:

• My drive_d is a top-level folder — a "Shared Folder" in Synology parlance. There are other shared folders peer to my drive_d, but no mounts or anything beneath drive_d
• Synology doesn't seem to have findmnt on their installations anyway ☹️; see below:

casey@Caseys-MaxBook-Pro ~> ssh syn
casey@syn's password: 

Using terminal commands to modify system configs, execute external binary
files, add files, or install unauthorized third-party apps may lead to system
damages or unexpected behavior, or cause data loss. Make sure you are aware of
the consequences of each command and proceed at your own risk.

Warning: Data should only be stored in shared folders. Data stored elsewhere
may be deleted when the system is updated/restarted.

casey@DiskStation:~$ which findmnt
casey@DiskStation:~$ 

[JonathanTreffler]

• Synology doesn't seem to have findmnt on their installations anyway ☹️; see below:

The findmnt command is convenient, but not the only way to list mount points on Linux, see https://linuxopsys.com/topics/list-mounted-drives-on-linux . Surely at least one other method must work on Synology :)

[cliss]

Ah, apologies; wasn't sure if you needed the output of findmnt specifically.

Here's mount; you'll note that Archive doesn't appear anywhere — that's my drive_d.

casey@DiskStation:~$ mount
/dev/md0 on / type ext4 (rw,noatime,prjquota,rootprjquota,data=ordered)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=1987552k,nr_inodes=496888,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/synomonitor type cgroup (rw,nosuid,nodev,noexec,relatime,name=synomonitor)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /proc/bus/usb type devtmpfs (rw,nosuid,size=1987552k,nr_inodes=496888,mode=755)
tmpfs on /run/user/108668 type tmpfs (rw,nosuid,nodev,relatime,size=398376k,mode=700,uid=108668,gid=108668)
/dev/mapper/cachedev_0 on /volume1 type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,syno_allocator,subvolid=256,subvol=/@syno)
none on /config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
/dev/mapper/cachedev_0 on /volume1/@docker type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,syno_allocator,subvolid=256,subvol=/@syno)
/dev/mapper/cachedev_0 on /volume1/@docker/btrfs type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,syno_allocator,subvolid=256,subvol=/@syno)
nsfs on /run/docker/netns/default type nsfs (rw)
nsfs on /run/docker/netns/c0728a21d575 type nsfs (rw)

[JonathanTreffler]

/dev/mapper/cachedev_0 on /volume1 type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,syno_allocator,subvolid=256,subvol=/@syno)

Is /volume1 the parent directory of your drive_d ?

[cliss]

Yeah, kinda. Now we're getting into the depths of how Synology treats things, which is more than you asked for. 🤪

Basically, I have a "Volume" (group of physical drives treated as one):

So I have four physical disks which are one btrfs file system, with two-drive redundancy:

On that volume are several "Shared Folders". These are the actual folders that show up on their equivalent of Finder/Windows Explorer. Here's the place where they're defined:

And "Finder"/"Windows Explorer":

In my case, Archive is where I keep… everything, and what I was trying to use as drive_d.

However, volume1 is the parent for all of those "Shared Folders", to your point.

In my old Synology, this worked no problem. Like I said in my original post, I tired to just move that image over, and failed, though it was probably user error on my part. In setting up anew, something is making Backblaze not see the contents of drive_d, even though Wine can. 😭

[JonathanTreffler]

As far as I know (and I could be wrong) the filesystem used by a Synology devices depends on the hardware of the device and different Synology devices use different file systems. Are you sure you previously also used btrfs ? (If you transfered the HDDs to the new Synology the filesystem could obviously not change, but if it is a new Synology with new HDDs it could have).

[cliss]

No, you're correct. My old Synology is ancient — a DS1813+ from 2013 — and the new one is a DS1621+.

Synology advises you to just dump the old drives in the new enclosure, but even leaving aside the fact that my enclosure is smaller now, I wanted to switch to btrfs. Hence me starting anew, and being a thorn in your side. 😖

[JonathanTreffler]

Hence me starting anew, and being a thorn in your side. 😖

No problem at all :)

My guess is that BTRFS is giving more information to Wine than your previous filesystem, which gives it to Backblaze, which causes Backblaze to not detect it as a local drive and skip it.

I will look into mitigations (like https://github.com/mpartel/bindfs), but FUSE is very tricky inside containers and would require extra permissions for the docker.

[fetzu]

@JonathanTreffler I have tried setting this up today on a new Synology NAS (using Brtfs as a file system) and I am having the same issue: wine is unable to see inside D:\ even though I am able to see the contents of /drive_d/ from inside the container's Linux CLI.

I'll also try to do some research, see if I can come up with some solution.

NOTE: I think this issue is also related to #55.

EDIT: My issue was actually unrelated and only due to setting my PUID/GUID using the wrong environment variables. Using a specifically created user/group and giving it the right permission worked.