Solved DSBMD vs Thunar Daemon

BostonBSD

Member

Reaction score: 3
Messages: 22

This is not a high concern, however, it is a question.

I have several USB thumb drives that I plug into Windows/FreeBSD/OpenBSD/Linux.

They are formatted fat32.

They always work with Linux/Windows/and FreeBSD if I use the DSBMD automount daemon.

However, if i do not use DSBMD [OpenBSD has something called hotplug], only a small portion of the folders and files show up.

At first I thought it was an OpenBSD issue...then I noticed it happening in FreeBSD whenever I use any automount daemon besides DSBMD, Thunar Daemon for example.

Does anyone know what could be causing that?

======
If I open a terminal to the folder and enter: ls

It will show:

Code:
ls: Folder1: No such file or directory
ls: Folder2: No such file or directory
ls: MyFolder: No such file or directory
ls: Anotherfolder: No such file or directory
ls: perlfolder: No such file or directory


Then list the folders that it can see {they all have the same permissions and owner|group}.
 
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

I just tried this with a manual mount command, it has the same result:

mount -t msdosfs /dev/da0s1 /media

what do you mean with
"only a small portion of the folders and files show up" ?

It mounts the file system, however, only 3 of 8 folders are recognized.

Code:
myname@BostonBSD ~ [1]> sudo mount -t msdosfs /dev/da0s1 /media
myname@BostonBSD ~> cd /media
myname@BostonBSD /media> ls
ls: Recipes: No such file or directory
ls: books: No such file or directory
ls: fbsd: No such file or directory
ls: nomadBSD: No such file or directory
ls: perl: No such file or directory

SYSTEMS  plans  wallpapers
 
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

There must be filesystem metadata of the contents, however, for some reason regular mounting does not recognize 5 of 8 folders and lists them as non-existent [although it does see the record of them in the metadata].

=======

This has been a habitual problem with OpenBSD/FreeBSD, DSBMD solves it perfectly.
However, I never understood what the real problem is.
 

Alexander88207

Well-Known Member

Reaction score: 131
Messages: 289

Hmm... interesting.

Just to be sure its not a permssion problem, what if you run ls as root on that drive?
 
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

Now this is with DSBMD:

Code:
myname@BostonBSD /> dsbmc-cli -m /dev/da0s1
myname@BostonBSD /> cd /media
myname@BostonBSD /media> ls
FILES       MEMORY_CARD
myname@BostonBSD /media> cd FILES
myname@BostonBSD /m/FILES> ls
Recipes    books     plans perl
SYSTEMS    fbsd       nomadBSD   wallpapers
 
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

It does look like a permissions issue check this out:

Code:
myname@BostonBSD ~> sudo mount -t msdosfs /dev/da0s1 /media
myname@BostonBSD ~> cd /media
myname@BostonBSD /media> sudo ls
Recipes        books       plans    perl
SYSTEMS        fbsd        nomadBSD    wallpapers
myname@BostonBSD /media> ls
ls: Recipes: No such file or directory
ls: books: No such file or directory
ls: fbsd: No such file or directory
ls: nomadBSD: No such file or directory
ls: perl: No such file or directory
SYSTEMS    plans wallpapers
 
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

Now if I try to mount as a user rather than root:

Code:
myname@BostonBSD /media [1]> mount -t msdosfs /dev/da0s1 /media
mount_msdosfs: /dev/da0s1: Operation not permitted


DSBMD must circumvent these permissions somehow.
 
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

This is the same issue that I had like 7-8 years ago with FBSD, after dsbmd was created I never thought about it again. I have the same permissions issue I had before.

Anyways,

I added:


Code:
# This is for USB mounting by users in the operator group
add path 'da[0-9]*' mode 0660 group operator
add path 'msdosfs/*' mode 0660 group operator


to devfs.rules [I do not think I need the second line, I added it anyways]
I am in the operator group.

I did a service devfs restart.

Code:
myname@BostonBSD /mnt> sudo mkdir gmounts

myname@BostonBSD /mnt> ls
gmounts

myname@BostonBSD /mnt> sudo chown myname:myname gmounts/

myname@BostonBSD /mnt> mount -t msdosfs /dev/da0s1 /mnt/gmounts

myname@BostonBSD /mnt> ls
gmounts

myname@BostonBSD /mnt> cd gmounts

myname@BostonBSD /m/gmounts> ls
ls: Recipes: No such file or directory
ls: books: No such file or directory
ls: fbsd: No such file or directory
ls: nomadBSD: No such file or directory
ls: perl: No such file or directory
SYSTEMS    plans wallpapers

myname@BostonBSD /m/gmounts [1]> sudo ls
Recipes        books        plans    perl
SYSTEMS        fbsd        nomadBSD    wallpapers


I can mount a USB drive as a user now, however, the issue remains the same.

Listing the directory is incomplete as a user.
Listing the directory is complete as root.
 
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

vfs.usermount=1 is already set.

I think this has something to do with writing the USB drive.
It does mount correctly as a user mount and I can read from some of the folders correctly [as a user].

However, some of the folders are not listed to the user, but are listed to root.

Nevertheless, I think the best solution is to back up the drive, reformat it, and rewrite it as a user.

Although it does irk me that windows, linux, and the dsbmd daemon can read it correctly, but FreeBSD/OpenBSD cannot without dsbmd.

[I suspect that some of the folders were written as root, some as a user. The folders written as root may have some sort of permission bit set which prevents me from viewing them as a user. Somehow DSBMD circumvents this.]

Let this be a warning when copying files to thumbdrives as root/sudo/doas
[you might not be able to read them as a user without special configs]
 
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

Alright I think I just narrowed this down.

Creating a directory as root, when mounted with dsbmd will create a ghostfile, when mounted with a system mount command.

However, creating a directory as root, when mounted with the system mount command will not create a ghostfile.

I'm going to compile a demonstration and post it here.


mount with dsbmd
create directory as root
ls as user. [all directories should be visible]
unmount
mount with system mount
ls as user. [you should see a ghostfile/directory]
create directory as root
ls as user. [new directory should be visible along with ghostfile]
unmount
mount with dsbmd
ls as user. [all directories should be visible]
 
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

I was only able to reproduce this once [notice that I have already fixed the other folders at this point].
Subsequent trials were not as expected [all directories were visible regardless].

This started as a mount with dsbmd.
Code:
myname@BostonBSD /m/BACKUP [1]> sudo mkdir testdir2/

myname@BostonBSD /m/BACKUP> ls
Recipes    books      plans perl       testdir2
SYSTEMS    fbsd       nomadBSD   testdir    wallpapers

[this was unmounted via the gui]

myname@BostonBSD /m/BACKUP> cd /mnt/gmounts/

myname@BostonBSD /m/gmounts> ls

myname@BostonBSD /m/gmounts> cd ..

myname@BostonBSD /mnt> mount -t msdosfs /dev/da0s1 /mnt/gmounts

myname@BostonBSD /mnt> cd gmounts

myname@BostonBSD /m/gmounts> ls
ls: testdir2: No such file or directory
Recipes    books      plans perl       wallpapers
SYSTEMS    fbsd       nomadBSD   testdir
 
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

As I have already stated subsequent trials were not as expected
[all directories were visible regardless, I couldn't reproduce this]

Code:
myname@BostonBSD /media> dsbmc-cli -m /dev/da0s1

myname@BostonBSD /media> cd BACKUP/

myname@BostonBSD /m/BACKUP> sudo mkdir ROOTS_DSBMD_DIRECTORY

myname@BostonBSD /m/BACKUP> ls
ROOTS_DSBMD_DIRECTORY books                 nomadBSD
Recipes               fbsd                  perl
SYSTEMS               plans            wallpapers

myname@BostonBSD /m/BACKUP> cd ..

myname@BostonBSD /media> dsbmc-cli -u -f /media/BACKUP/

myname@BostonBSD /media> mount -t msdosfs /dev/da0s1 /mnt/gmounts

myname@BostonBSD /media> cd /mnt/gmounts/

myname@BostonBSD /m/gmounts> ls
ROOTS_DSBMD_DIRECTORY books                 nomadBSD
Recipes               fbsd                  perl
SYSTEMS               plans            wallpapers

myname@BostonBSD /m/gmounts> sudo mkdir ROOTS_MOUNT_DIRECTORY

myname@BostonBSD /m/gmounts> ls
ROOTS_DSBMD_DIRECTORY books                 perl
ROOTS_MOUNT_DIRECTORY fbsd                  wallpapers
Recipes               plans
SYSTEMS               nomadBSD

myname@BostonBSD /m/gmounts> cd ..

myname@BostonBSD /mnt> umount -f /dev/da0s1

myname@BostonBSD /mnt> dsbmc-cli -m /dev/da0s1

myname@BostonBSD /mnt> cd /media/BACKUP/

myname@BostonBSD /m/BACKUP> ls
ROOTS_DSBMD_DIRECTORY books                 perl
ROOTS_MOUNT_DIRECTORY fbsd                  wallpapers
Recipes               plans
SYSTEMS               nomadBSD

myname@BostonBSD /m/BACKUP>


I wish I knew what causes this ghostfile effect, it's been bugging me for years.

====

Anyways, if anyone else sees this sort of issue, the way I fixed it was by reformatting the drive and copying the folders over as a user, with the drive mounted with:

mount -t msdosfs /dev/da0s1 /mnt/gmounts

command [copying the ghostfolders over as a user with dsbmd keeps them as ghostfolders].

If I saw this again, I'd suggest using the Thunar-Daemon as a drop-in replacement for dsbmd as a gui automounter.


=====
EDIT: I'm posting this several days later.
This is the DSBMD log from the time period, of the recorded failure ~8:00-8:30PM Jan 12th.
=====

dsbmd: Device /dev/da0s1 unmounted from /media/BACKUP by UID 1001 on Tue Jan 12 19:57:15 2021
dsbmd: Unmounting of /dev/da0s1 mounted on /mnt/gmounts by UID 1001 failed: Device busy on Tue Jan 12 20:17:13 2021
dsbmd: Device /dev/da0s1 unmounted from /mnt/gmounts by UID 1001 on Tue Jan 12 20:17:16 2021
dsbmd: Device /dev/da0s1 mounted on /media/BACKUP by UID 1001 on Tue Jan 12 20:17:27 2021
dsbmd: Client with UID 1001 connected on Tue Jan 12 20:18:55 2021
dsbmd: Client with UID 1001 disconnected on Tue Jan 12 20:18:55 2021
dsbmd: Device /dev/da0s1 unmounted from /media/BACKUP by UID 1001 on Tue Jan 12 20:19:03 2021
dsbmd: Client with UID 1001 connected on Tue Jan 12 20:19:05 2021
dsbmd: Device /dev/da0s1 mounted on /media/BACKUP by UID 1001 on Tue Jan 12 20:19:06 2021
dsbmd: Client with UID 1001 disconnected on Tue Jan 12 20:19:06 2021
dsbmd: Client with UID 1001 connected on Tue Jan 12 20:20:39 2021
dsbmd: Unmounting of /dev/da0s1 mounted on /media/BACKUP by UID 1001 failed: Device busy on Tue Jan 12 20:20:39 2021
dsbmd: Client with UID 1001 disconnected on Tue Jan 12 20:20:39 2021
dsbmd: Client with UID 1001 connected on Tue Jan 12 20:20:57 2021
dsbmd: Unmounting of /dev/da0s1 mounted on /media/BACKUP by UID 1001 failed: Device busy on Tue Jan 12 20:20:57 2021
dsbmd: Client with UID 1001 disconnected on Tue Jan 12 20:20:57 2021
dsbmd: Unmounting of /dev/da0s1 mounted on /media/BACKUP by UID 1001 failed: Device busy on Tue Jan 12 20:21:02 2021
dsbmd: Device /dev/da0s1 unmounted from /media/BACKUP by UID 1001 on Tue Jan 12 20:21:03 2021
dsbmd: Unmounting of /dev/da0s1 mounted on /mnt/gmounts by UID 1001 failed: Device busy on Tue Jan 12 20:24:20 2021
dsbmd: Device /dev/da0s1 unmounted from /mnt/gmounts by UID 1001 on Tue Jan 12 20:24:21 2021
dsbmd: Device /dev/da0s1 mounted on /media/BACKUP by UID 1001 on Tue Jan 12 20:24:33 2021
dsbmd: Unmounting of /dev/da0s1 mounted on /media/BACKUP by UID 1001 failed: Device busy on Tue Jan 12 20:25:17 2021
dsbmd: Device /dev/da0s1 unmounted from /media/BACKUP by UID 1001 on Tue Jan 12 20:25:18 2021
dsbmd: Device /dev/da0s1 unmounted from /mnt/gmounts by UID 1001 on Tue Jan 12 20:26:04 2021
dsbmd: Unmounting of /dev/da0s1 mounted on /mnt/gmounts by UID 1001 failed: Device busy on Tue Jan 12 20:27:10 2021
dsbmd: Device /dev/da0s1 unmounted from /mnt/gmounts by UID 1001 on Tue Jan 12 20:27:11 2021

It looks like there were some unmount failures. If I were to guess, the daemon wasn't finished writing the system volume information prior to the unmount request. For some reason DSBMD can still read the system volume, but regular system mount commands cannot. I wonder how dsbmd differs from other daemons in this respect.

Is there any way to write system volume information differently, is it interlaced with volume changes or does it change after a period of inactivity?
 
Last edited:
OP
B

BostonBSD

Member

Reaction score: 3
Messages: 22

I disabled dsbmd, the thunar-daemon starts with xfce, everything should work as intended now.

[dsbmd appears to automatically handle fuse {userspace file systems, usb drives, cloud drive, rclone, megadrive, onedrive..you get the idea} mounts, without dsbmd I had to add the "fuse" kernel module to my kld_list in rc.conf].

sysrc kld_list+="fuse"

I'm going to mark this as solved.

~ The issue appears to be in relation to DSBMD [and how it writes system volume information], however, I was never able to fully clarify the source. I have very limited knowledge of FUSE/GVFS and automount daemons. There were two mount daemons [the word automount is slightly misleading] running at the same time [dsbmd and thunar-daemon], this may have impacted the results.
 
Last edited:
Top