I am able to mount and see the files on /mnt/NAS/MyShare on the device (Raspberry Pi5)
However the library does not index any files (Flac + DSD). Tried rebooting etc. No errors while mounting in the logs.
The weird part is I have another X86 based Volumio device which is able to index it perfectly well.
I tried various mounting options like vers=SMB2.0,rw etc. Nothing makes a difference. The mounting works, not scanning.
Please hit rescan and provide the log when finished. The only way we can support you.
No logs, no support.
Sorry no luck. Also tried 1.0 and 3.0 yesterday.
I am able to see the files on /mnt/Music directory. But the UI doesn’t show it’s scanning.
You mean /mnt/NAS/Music.
SPNEGO login failed: {Access Denied} A process has requested access to an object but has not been granted those access rights.
@KCAudio
This error means that you NAS is blocking the credentials. Are you sure the user has access to folders and files?
So the user can mount the share, but seems to have no access to the files and folders on this share. For this reason the scan can’t start and won’t generate errors as it can’t access them.
@nerd
Do you you see any other reason for the failed scan?
The SPNEGO trace is from the anonymous share browse (smbclient -L … -N) that runs during Add Share, not from the authenticated mount. The NAS refusing anonymous listing is normal and unrelated. The mount that follows succeeds - /proc/mounts shows it live on //192.168.0.220/D/Music with username=ketan, vers=3.1.1, and df reports 13T total with 12T used, so kernel CIFS is reading the server correctly.
The scan failure is in mpd.log:
2026-04-17T16:08:38 exception: Failed to access /var/lib/mpd/music/NAS/Music: Value too large for defined data type
2026-04-17T16:10:34 exception: Failed to access /var/lib/mpd/music/NAS/Music: Value too large for defined data type
That is EOVERFLOW on stat(). It happens when a 32-bit application reads inode numbers from a CIFS mount where the server returns 64-bit FileIds. Volumio’s armhf userland is 32-bit, the 13T share almost certainly backs onto a filesystem that hands out 64-bit inodes, and the current mount carries serverino, which is the kernel default on every SMB dialect from 2.0 upward. mpd aborts before it reads a single file. This is why changing vers= between 1.0, 2.0, 2.1, 3.0 and 3.1.1 made no difference - dialect does not control inode width, serverino does. It also explains why @KCAudio’s x86 Volumio indexes the same share cleanly: x86 is a 64-bit userland and stat() there has no trouble with 64-bit inode numbers.
@KCAudio the fix is to add noserverino to the share options. In Settings > My Music > Sources, edit the NAS entry, open Advanced Options, and append noserverino to the Options field. Save, then toggle the share off and on (or reboot) so the mount is redone with the new flag. vers= does not need to change for this fix to work, though vers=2.1 is a reasonable hedge against the 3.1.1 turbulence seen on kernel 6.12 Bookworm builds. Either value is fine as long as noserverino is present.
vers=2.1,noserverino should do the trick. Comma, no spaces.
Kind Regards,
Sometimes I don’t like your brains… 
I extracted it from the log, added it to the reply, but removed it again
Hey @Wheaten,
Plural is generous. It is one grey brain cell on duty, and that one was already overkill for this. The rest are melted, hiding quietly in the corner.
Kind Regards,
Unfortunately that didn’t help. Also tried a different directory (DSD) after rebooting.
https://logs.volumio.org/volumio/pQbUiVf.html
PS: I can do a cat on a Flac file and it works. So the device is able to get the data from the NAS. but mpc play command gives this error
error parsing song numbers from: xxx.flac
Hey @KCAudio,
Your two logs do not come from the same software state. The first log shows Samba 4.17.8-Raspbian throughout (nmbd, winbindd, smbd). The second log, taken about two hours later on the same device, shows Samba 4.17.12-Debian throughout, with a string of startup errors about missing /var/log/samba paths that are a textbook signature of the Debian samba packages being dropped onto a Raspbian-flavoured image.
That transition does not happen on its own. It means apt-get upgrade, or an apt install pulling in Debian samba packages, was run between the two log captures. Volumio 4 is built on a fixed package set and is not safe to apt upgrade. Doing so silently pulls in whatever else is newer upstream (libsmbclient, libldb, libtalloc, python3-samba and related), and from that point on the system is no longer a supported Volumio install. We cannot usefully troubleshoot against it.
Note also that the CIFS client sits in the kernel, not in the Samba userland. Upgrading smbd and winbindd does nothing for the scan behaviour you are chasing. It just contaminates the rest of the system.
Please flash Volumio cleanly to the SD card, restore the same share configuration, and repeat the test. At the same time, when you post the new log, include the make and model of your NAS and the exact settings of the share entry under Settings, My Music, Sources, Edit Mount: share name, remote directory, username, the value you have in the vers= field, and the full contents of the Options field.
Kind Regards,
You are right. I was messing with apt-get sources but not to fix this problem but the Kiosk / Touch plugin as it was not installing xinit and some other X11 packages needed for Chromium.
I have reflashed Volumio again, and used your suggested vers=2.1,noserverino setting but it still is the same.
I can read and write files from the share mount on RPi5 via ssh command line. It’s just that Volumio is unable to scan the music files into the DB. I can see all the flac/DSF files already in the /mnt/NAS/Music and ./DSD folders. For some reason the scanning process isn’t working. And I see no errors in the logs.
The current share works great on an X86 device with Volumio installed.
@nerd Anything can be done with this? Seems like mounting and rw are already working but the music is not being scanned by Volumio.
PS: I copied my music to a smaller 1TB drive on the same server and now Volumio is scanning it 
Hey @KCAudio,
Thanks for the new log and for the very useful detail that copying your music to a 1TB drive on the same NAS made the scan work. That single observation is what pins this down, and I owe you an updated explanation because the noserverino step I suggested earlier was only half the story.
Same NAS, same protocol, same credentials, same mount options, same mpd. The only variable that changed between “fails” and “works” is the size of the share’s underlying filesystem: 13T versus 1T. That rules out inode width, SMB dialect, ACLs, and the reparse=nfs path, and points squarely at a size-dependent stat overflow.
Took time to research the problem:
The mechanism is well documented. EOVERFLOW from stat on a CIFS mount can come from any field in struct stat or statvfs that does not fit in the binary’s 32-bit data types, not just the inode number. The Raspberry Pi forum thread on it states it directly: “EOVERFLOW can also mean that the inode number does not fit in 32 bits” and the proper fix for an affected program is to rebuild it with -D_FILE_OFFSET_BITS=64 (https://forums.raspberrypi.com/viewtopic.php?t=38672). The same diagnosis appears in Ubuntu Launchpad bug 767244, where 32-bit mountpoint returns EOVERFLOW on a CIFS share and is only fixed by recompiling with 64-bit offsets (https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/767244), and in Ubuntu Launchpad bug 486667, which lists mpd by name as one of the programs that fail to traverse CIFS shares for exactly this reason (Bug #486667 “stat() fails on cifs shares” : Bugs : linux package : Ubuntu).
The earlier nounix,noserverino workaround addresses this when the inode number is the field that overflows. That is the case you can find documented all over the web (https://stackoverflow.com/questions/2438890, Bug #455122 “gcc chokes under Karmic's smbfs” : Bugs : gcc-defaults package : Ubuntu). When the inode is fine but the filesystem-size or block-count fields are too large, noserverino does nothing. That matches your case: a 13T volume reports allocation counters that do not fit in 32-bit fields, and a 1T volume reports values that do, which is why moving the music to the 1T drive resolved the scan immediately.
The architectural piece behind this is that Volumio’s ARM userland is 32-bit armhf on every Pi, including the Pi 4 and Pi 5 with their aarch64 kernels. That means mpd on your Pi 5 is the 32-bit build.
So there is no SMB option you can set on the Pi side that will make scanning the 13T share work. The realistic options are:
A 64-bit aarch64 Volumio build would also avoid this class of failure but is not currently a shipping option.
Kind Regards,
Appreciate the lengthy response.
For those who stumble here with the same problem:
TLDR: 32bit OS on Raspberry Pi won’t work with large SMB shares (2.2TB+)
