FUSE, GNOME and SAMBA

[JohnnyPI]

Hello people,
Haven't had a freeBSD box running for quite sometime and I have run into a glitch trying to mount an ext4 internal harddrive,

freebsd-version && uname -a
13.1-RELEASE
FreeBSD jupiter 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC amd64

I am using fuse to mount the partition here's my fstab file....

# Device    Mountpoint    FStype    Options    Dump    Pass#
/dev/ada1p2    /        ufs    rw    1    1
/dev/ada1p3    none        swap    sw    0    0
proc        /proc        procfs    rw    0    0
/dev/ada0p1    /mnt/linux    fuse    rw,mountprog=/usr/local/bin/lklfuse,type=ext4,allow_other    0    0

As you can see I am using lklfuse. The problem I am getting is the files are only visible from the command line, not through gnome shell and when I setup a samba share it's contents still are not visible over my little LAN.

Am I approaching this correctly? Is lklfuse the right approach in this situation. I chose it because I require read write privileges.

Thanking you in advance,
Jonathan.

 

[ralphbsz]

The problem I am getting is the files are only visible from the command line, not through gnome shell ...

If the files are visible and accessible from the command line, then do your debugging there. Much easier than working with DEs. One thing in particular you need to check: What are the permissions and user/group numbers on the files? For example, if the ext4 file system uses different user/group IDs, and the files are by default set for "rw-------", then they may seem "visible" for you from the command line when logged in as root, but they might become invisible if the DE's file manager runs as a normal user.

... and when I setup a samba share it's contents still are not visible over my little LAN.

In theory, if a file is fully visible in the file system, Samba should be able to serve it. I would enable debug logging in Samba, and read the logs. One warning: Samba likes to use file locking on the server side. Actually, I should have said "may have to" instead of "likes", because file locking is necessary to reflect the semantics of Windows accesses. It could be that the FUSE file system does not implement the full locking operations.

But my hunch is that your problem is much simpler, and may be just permissions and user/group mapping.

Am I approaching this correctly? Is lklfuse the right approach in this situation. I chose it because I require read write privileges.

General comment: I would never use second-tier or grey-box file systems in production, in particular not for write accesses. Why not? The internal metadata of file systems is exceedingly complex, and the details of the semantics of what on-disk metadata structures really mean is between hard and impossible to figure out. Within the original source code of a file system such as ext4, that is less of a problem, because (a) the authors of the code that interprets or modifies data structures are also the ones who design and write the data structures, and (b) file system code is intensely tested in its original environment before being deployed. When other operating systems write file system adaptors (such as the Fuse-based code you're running), they don't have those benefits, and the result is often buggy. There is real risk of corrupting the on-disk file system when running this way.

What I conclude from that: If you have a Linux-specific file system (such as ext4 or BtrFs), then access it from Linux. If you have a Windows file system (such as NTFS), access it from Windows, and similarly access UFS from the *BSD that wrote it. In your situation, I would not use a FreeBSD machine as a server for an ext4 file system. Instead, I would run a small VM on your machine, boot Linux on it, and then use Linux to distribute the content, for example via NFS or CIFS.