File system compatibility with CIFS

Question

I've been using my Raspberry Pi as a music file server, but I'm not happy with it. The current setup uses a samba server on my RPi with a WD Passport USB drive formatted as vfat. This serves as the library for my Sonos music system: Sonos mounts the drive, and lists all of the music it finds there in a menu for me to choose from.

The Sonos interface seems to operate smoothly with the RPi Samba server most of the time. However, it does not work so smoothly with my MacOS. I use my Mac to maintain the music library, and there are two primary niggling issues:

1. user permissions must be changed through the Samba configuration to enable deletions and additions in the music library
2. browsing the Samba music share on my RPi in the Mac's Finder app reveals numerous "omissions & artifacts", whereas browsing a folder with exactly the same content on the NetgearNAS with CIFS is flawless; see the figure below.

A friend uses a NetgearNAS as the fileserver for his Sonos system. It works very reliably, and the "artifacts" do not show up in Finder. His NetgearNAS is configured to use CIFS (and only CIFS). I'd like to try CIFS on my RPi, but my research so far has only added to my confusion.

Finally, my questions:

1. SMB and CIFS seem to be closely related, but are they "the same thing"? If not, what are the differences?

2. Some sources refer to CIFS as a file system (in the sense that ext4, FAT32, etc. are file systems), while others refer to it as a networking protocol. As there is no CIFS extension for mkfs, references that refer to CIFS as a file system would seem to be misleading - or am I missing something?

3. If CIFS is only a networking protocol, is it limited to a specific file system?; i.e. may one use FAT32 or ext4 with CIFS? Does the file system used with CIFS affect its use as a cross-platform server protocol?

Answer 1

vfat is a very limited filesystem, it's completely unsuitable to any networked use and any multiuser environment (it's the ancient MS-DOS filesystem). In short, don't use VFAT for anything but USB thumb drives, for maximum compatibility.

Basically all of your problems come from the fact that MacOS tries to store extended attributes, file rights, etc through SMB/CIFS to VFAT that doesn't support any of that, nor does it support very long file names, or UTF-8 file names, or anything of interest to modern users.

Just use a real, normal Linux filesystem on your USB drive (ext4, xfs) and all will be fine and dandy. That will certainly solve the problems with missing files, wrong rights and permissions, artifacts, etc.

Regarding the other questions:

• SMB and CIFS are different names for the same thing, the Microsoft Network Filesystem (Server Message Block protocol). There is some confusion here, because CIFS actually was the first version of it (SMB version 1.0), and was superseded by newer versions (SMB v. 2.0, 3.0, 3.1, ...). However on Linux, for some reason the first version was called 'smbfs', and the newer ones 'cifs'. Anyway nowadays on both Linux and MacOS this doesn't make any difference, both are interchangeable.

• SMB/CIFS is a network file system. It has no direct relation at all with a block file system. It's a file system in the sense that it provides a file abstraction and its common I/O modes; however you can use any network file system (NFS, SMB, WebDAV, AFP...) to share data from any block file system (FAT32, ext4, HFS+, xfs, NTFS, ZFS...).

• Different block file systems provide different features (direct IO, POSIX ACLs, Windows ACLs, extended attributes, file streams, "hollow" files, file versioning, metadata versioning, subvolumes, volume snapshots...). Different network file systems provide also different features. The way the features from the network file system maps onto the underlying block file system vary greatly and are an unending source of confusion, pain, and bugs.

For instance CIFS, originating from Windows, by default uses Windows ACLs, which unfortunately doesn't map one-on-one to the POSIX ACLs of most Unix/Linux filesystems. Nowadays Samba works around this by using extended attributes to store actual Windows ACLs, however if the underlying block file system doesn't support xattr, you'll have problems.

Answer 2

Let me try to answer a few of your questions.

First CIFS is a version of the SMB protocol. See e.g. the wiki page of SMB.

The second question was about file system vs. networking protocol. CIFS/SMB are networking protocols. The thing with the file system comes merely from the linux world: You can mount such a share like any other file system (assuming the rights) to be able to access the files transparently. So you have a mount.cifs program that handles the mounting process of this specific protocol.

According to you third question: No networking protocol is in any way related to the underlying file system. It only specifies how data are sent over the line (in an abstract way). The data might come from a hard disk directly (aka a file system) or might be generated dynamically (think what would happen if you exported your /proc or /sys folders....).

However, the protocol was designed with a certain use case in mind. This was the FAT system as far as I know. Extensions were made to allow for extended rights also under Linux/Unix. Here I am a bit weary what is possible and what is implemented (especially as both server and client must find a common maximum protocol version). Different software versions on the various machines might come into play here, but I am not sure.

---

Instead of giving you basic information that needs further investigation by you I will instead address some of your stated problems:

Your "omissions & artefacts" are due to codepage/charset problems. It happens only for non-ascii characters, right? I do not know how it is set up at the moment. Can you first verify, that the files on the USB device are written with correct names in the file system? Then verify that the RPi can read the files as well (without CIFS, go there using ssh or directly attached monitor/keyboard).

Different underlying file systems support different sets of characters in file names and thus SMB can be configured to treat the filenames differently. This is a feature to support as many underlying file systems as possible (see man smb.conf). This can also be a mount problem on your client, where the wrong encoding is assumed. So start by building up the system and verifying each step.

Regarding the user permission issues you mentioned, you need either authenticated access (user+password), configure samba/cifs server to use default user with default permissions or your storage is the problem. Again from bottom up:

• What user/group do the files in the USB storage belong to? They are lying on vfat, where no owner is stored. Thus Linux kernel applies a user to the files depending on the mount options.
• Verify that all files/folders are of this user (again on the Rpi using ssh/terminal access).
• Check if new created files (from the terminal) get the same rights. If not, adopt your mount configuration (mount options uid, gid, umask, potentially dmask and fmask). See man mount.
• Create a file/folder from SMB/CIFS and verify the UID/GID/rights as well. If it is a guest only access, the create mask and directory mask of the samba configuration (man smb.conf) might be sufficient. If not, you should describe your problems more in depth.