Bug 13687 - File saving and tmp .sb- file issue with vfs_fruit.
Summary: File saving and tmp .sb- file issue with vfs_fruit.
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 4.9.2
Hardware: All Mac OS X
: P5 major (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2018-11-20 08:50 UTC by thomas.schwark
Modified: 2019-03-02 14:04 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description thomas.schwark 2018-11-20 08:50:26 UTC

first of all thanks for fixing my other bug report https://bugzilla.samba.org/show_bug.cgi?id=13646. The respective issue is resolved for us in samba 4.9.2.

Unfortunately we are experiencing another bug.

Steps to reproduce:
1	Connect to the same samba share with two different users from two different macs (tested with High Sierra and Mojave clients). Both macs have to be connected to the same share before continuing.
2	Create a new pages file and save it somewhere on the share, add some content to it and re-save.
3	Close the .pages file on the first mac and open it on the second, make some changes, save and quit pages.
4	Open it on the first mac.

Expected result:
Both macs should see the changes the other mac has done in the file and there should not be any leftovers in the directory of the file.

Actual result:
The second mac can not see the changes that have been done with the first mac. After disconnecting and reconnecting to the share the changes are visible for the mac that did the reconnecting. This makes working on the share a big issue if I never know if the file has the latest changes in it.
This issue is not happening when setting setting fruit:aapl = no.

Additionally (I don`t know if this is another issue) with almost every changing, reopening and saving of the file alternating from the two macs new tmp files appear in the directory of the testfile. They all have the format *.*.sb-*-*, for example test.pages.sb-ae534a8e-YPZBad. These can also only be deleted after a reconnect to the share.

This is our current smb.conf as a result from testparm.
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[office]"
Processing section "[extra]"
Processing section "[scripts]"
Loaded services file OK.

Press enter to see a dump of your service definitions

# Global parameters
	disable spoolss = Yes
	dns proxy = No
	load printers = No
	log file = /var/log/samba/samba.log.%m
	max log size = 50
	printcap name = /dev/null
	security = USER
	server multi channel support = Yes
	server role = standalone server
	show add printer wizard = No
	unix extensions = No
	workgroup = LINUXSERVER
	fruit:model = Xserve
	idmap config * : backend = tdb
	inherit owner = windows and unix
	mangled names = no
	printing = bsd

	case sensitive = Yes
	comment = office
	create mask = 0770
	delete veto files = Yes
	directory mask = 0770
	force create mode = 0770
	force directory mode = 0770
	force group = +officesmbuser
	map archive = No
	nt acl support = No
	path = /data/office
	read only = No
	valid users = @officesmbuser
	veto files = /.DS_Store/._.DS_Store/
	vfs objects = catia fruit streams_xattr recycle
	recycle:exclude_dir = _trash,*.sb-*
	recycle:exclude = ?~$*,~$*,._*,.smbdelete*,*.*.sb-*,*~*.idlk
	recycle:maxsize = 0
	recycle:versions = yes
	recycle:touch = yes
	recycle:keeptree = yes
	recycle:subdir_mode = 0770
	recycle:directory_mode = 0770
	recycle:repository = _trash/%U
	fruit:veto_appledouble = no
	fruit:encoding = native

Thanks for looking into it and fixing in advance.

Kind regards

Comment 1 Ralph Böhme 2018-11-21 12:24:49 UTC
Does this work against a macOS server? We need to know if it's a client issue or really a Samba problem.
Comment 2 thomas.schwark 2018-11-21 12:59:35 UTC
What do you mean by "against" an macOS Server? We do not have a macOS server OS.
Comment 3 thomas.schwark 2018-11-21 13:08:18 UTC
But as stated in the issue the first part (changing files by different users that are already connected and they do not see the changes) does not happen when using fruit:aapl = no.

The second part or separate issue, I don't know (creating some tmp *.*.sb-*-* files and folders that do not disappear) does not happen when saving locally an the apfs formatted mac.
Comment 4 Ralph Böhme 2018-11-21 13:15:06 UTC
(In reply to thomas.schwark from comment #2)
Sorry, should have read "macOS SMB server", so any recent Mac will do, just enable file sharing in the system settings.
Comment 5 Ralph Böhme 2018-11-21 13:16:25 UTC
(In reply to thomas.schwark from comment #3)
macOS SMB server always uses AAPL, that's the reference.
Comment 6 thomas.schwark 2018-11-21 13:58:25 UTC
(In reply to Ralph Böhme from comment #4)
O.k., thanks for the clarification. We just tried with two different users and a new samba share from macOS smb.

The first part of this issue (changing files by different users that are already connected and they do not see the changes) does not happen. So all users do see the changes from other users. So it seems to be a samba / fruit issue.

The second part of this issue (creating some tmp *.*.sb-*-* files and folders that do not disappear) does also happen on the macOS smb server share. But would also be nice to see this solved.

Hope this helps.

Thanks a lot in advance.
Comment 7 thomas.schwark 2018-11-30 08:09:32 UTC
Just wanted to let you know that both issues are still present in samba 4.9.3.

Would be really nice to see a fix in the next release as we use it on daily basis.

Thanks a lot.
Comment 8 thomas.schwark 2018-12-23 00:18:00 UTC
Just wanted to let you know that both issues are still present in samba 4.9.4.

Thanks for looking into it in advance.

Merry Christmas ;)
Comment 9 thomas.schwark 2019-03-02 12:57:34 UTC
We actually discovered another bug when connecting from macOS clients. But before reporting I wanted to try what has changed until now.

I was able to install samba 4.10.0rc3 and dependencies by updating local PKGBUILDS from archlinux.

And it seems the newly discovered bug and the two in this report are no longer present.

It seems fruit is slower on small files now (rsync that took 4 minutes before now takes around 10 minutes), but the three bugs seem to be fixed. I don't know if the slower speed is a bug or not.

Thanks for fixing. This report can be closed.

Have a nice weekend and thanks for the hard work put into this ;)