Samba 4 share: files appear as directories

[jlovell]

I have a BT Home Hub 5 with an external hard drive attached, which I'm sharing using samba 4.11.6-1. Some mp4 video files on one of the partitions I'm sharing appear as directories on connected clients. This occurs with Windows 10, MacOS 10.15 and Linux Mint 19 clients.

The file is fine when accessed directly after logging in over SSH: it looks like a file and has the same SHA256 sum as the source file I copied it from so it's not corrupted. I've also set up MiniDLNA to access these files and my smart TV can play the files without issue, so I think it's a problem with the Samba share.

Has anybody else experienced a similar issue to this, or have any idea what might be causing it? I can provide UCI config and smb.conf.template if that helps (though I think the template is unmodified from the default).

[Smim0]

Are you sharing any other files rather than the mp4 videos? If yes do you have the same issue?

Please paste the /etc/config/samba4 config please

[jlovell]

Yes, I'm sharing a large number of other files: this partition on the drive stores ~10 years worth of collated files. Office documents, images, music files among others. I haven't noticed any issues with any of the other file types yet, and it's only a problem with some mp4 files: most of them work OK.

The relevant samba4 config is as follows:

config samba
	option workgroup 'WORKGROUP'
	option description 'Samba on OpenWrt'
	option charset 'UTF-8'
	option macos '1'

config sambashare
	option path '/mnt/sda1'
	option create_mask '0666'
	option dir_mask '0777'
	option read_only 'no'
	option users 'lovells'
	option name 'Lovells'
	option guest_ok 'no'

Thanks

[Smim0]

I would try with samba36 and also with nfs and see

[jlovell]

Thanks for the suggestion. NFS works: the files are correctly reported as files not directories. So it appears to be a problem with Samba.

I'll try samba36 later, but this won't be a long term solution as I use one of the other shares as a Time Machine backup, which I believe is only available with Samba 4. I also need the shares available from a Windows 10 Home Edition laptop, which precludes NFS as a long term solution.

Is there anything else I can do to try to diagnose this problem? Increase logging verbosity, for example?

[Smim0]

Sure, at least if it works with samba36 then you know that the issue is the version 4 then you will need to make sure that the issue is with samba4 with openwrt and not with any other linux machine. If it is the case I think you should open a ticket to report a bug with samba4 in openwrt.

BTW: Does the time machine backup work for you? can you share the samba config you use?

Thanks

[jlovell]

OK, samba36 seems to work: the files appear as files not directories. Reinstalling samba4 reproduces the problem, so it seems it is repeatable and not just a temporary glitch.

After playing with it a bit more, it seems like disabling the AAPL extensions (i.e. removing option macos 1) improves things: the files are now correctly displayed as files in Windows, Mac and Linux clients. In fact, the Mac client seems to be able to access the share happily, so it's not clear what benefit the AAPL extensions provide yet. Perhaps Time Machine will break on my next backup...

[jlovell]

Oh, and I have been backing up with Time Machine successfully for the past couple of weeks. Scheduled backups work fine, and I can browse Time Machine backups and restore files successfully,.

In addition to the config I posted in the previous message, I have the following share in /etc/config/samba4:

config sambashare
	option path '/mnt/sda2'
	option name 'TimeMachine'
	option timemachine '1'
	option create_mask '0666'
	option dir_mask '0777'
	option read_only 'no'
	option guest_ok 'no'
	option users 'lovells'

However, turning off the AAPL extensions seems to mess Time Machine up. I'll investigate this further...

[jlovell]

A bit more digging about has shed some light on this problem, and also a fix.

All the files which were incorrectly shown as directories had the xattr user.DOSATTRIB="", according to getfattr -d on the router. All other files which were fine had a base64(?) value of this attribute, e.g. user.DOSATTRIB=0sAAAEAAQAAAARAAAAIAAAAAAAAAAAAAAAALikjpQR1gE=.

Removing the invalid "" value of user.DOSATTRIB, using setfattr to either change it to something else or remove it altogether, meant the problem files were no longer displayed as directories. They were correctly shown as files and these mp4 files could be opened and played with VLC. Setting the value back to "" caused them to be displayed as directories again. So the problem can be reliably reproduced and fixed simply by changing this xattr, without having to disable the macos=1 option in the config file.

Another way to restore a valid user.DOSATTRRIB xattr is, with a Windows client, to right click on the problem file (displayed as a directory), then toggle the "Archive" property off and then on again, clicking Apply each time. This sets the xattr to a base64 string rather than the invalid "" value, so is probably preferable to just deleting this xattr.

So, it seems that somehow these files were either created with an invalid value for user.DOSATTRIB, or had it set at a later time. After getting rid of this invalid value using one of the methods above the files are fine. I'm not sure what actually caused this in the first place, but at least there is a simple fix.

I've opened a Github issue about this, which contains roughly the same information as in this post. As of 8th May 2020 the issue is still open, as we're waiting to see whether the problem returns. But if it was just a one-time issue with a bunch of files in a single file copy, it's unlikely to be a bug in the samba4-server package.

I'll mark this thread as resolved, so if in future anybody else has the same problem they can see the solution here: just change user.DOSATTRIB to something other than "" by e.g. using setfattr -x user.DOSATTRIB <file> on the openwrt router or by toggling the Archive property of the file on a Windows client.