Starting with Samba 4.2 a new VFS module called vfsfruit (instead of vfsapple) will be available to Samba that will address the most common challenges accessing the same set of data from OS X clients via AFP and SMB: File/record locking, encoding quirks introduced by Apple and especially access to Finder metadata and ressource forks.The author of the new module outlined the problems in 1.
![]()
TLDR; With vfs objects = catia fruit streamsxattr in my smb.conf, files created on the shares using Macs do not inherit permissions and get extended ACLs. BackgroundI'm setting up a NAS with a Samba share for our office, which is a 50/50 macOs/Windows 10 shop.
Everyone should have access to the shares using dedicated user accounts.I wanted to leverage the latest enhancements in Samba 4 when it comes to performance with Macs, and TimeMachine support, so I enabled the modules vfs objects = catia fruit streamsxattr ProblemPermissions are not inherited, and masks are not respected with these vfs objects set.
You also need to configure an avahi service to advertise the share. I am unsure of what distribution you are using but dropping a service file in /etc/avahi/services/timemachine.service with the following contents should get it to show up.
![]()
So I am unsure of any potential interactions with the other options on your smb configuration but the following should be all that is needed. globalworkgroup = SAMBAsecurity = userpassdb backend = tdbsamdurable handles = yeskernel oplocks = nokernel share modes = noposix locking = nofruit:advertisefullsync = truetimemachinepath = /srvbrowseable = Yesvfs objects = catia fruit streamsxattrfruit:aapl = yesread only = Noinherit acls = YesIf you are comfortable with Wireshark, doing a capture with the following filter before starting the backup should show why it is being rejected: 'smb2.aapl.volumecaps'. In the response if you expand the SMB2 sections, one should show a volume capabilities like the screen shot below.I'll rebuild the docker container that I use for my home server later today to see if I can reproduce it as well. I was able to compile the branch on FreeBSD 10.1 and have it work successfully. It sounds like something on your smb.conf is not quite right. Please see the config file below for what I used and compare against yours. globalworkgroup = SAMBAsecurity = userpassdb backend = tdbsamdurable handles = yeskernel oplocks = nokernel share modes = noposix locking = nofruit:advertisefullsync = truetimemachinepath = /srvbrowseable = Yesvfs objects = catia fruit streamsxattrfruit:aapl = yesread only = Noinherit acls = Yes.
Can you try and build ´s fork on bsd or are other things changed in the source code for bsd?It is located:, you can take the correct branch there.Overall Feedback after a week:. This samba release plays perfect with OSX (finally!).
It is considerably faster with the finder, especially file listing got much faster. Time machine backup works well. I have formatted the source partition to hfs+ now and hope that by this, the warnings 'your backup consistency needs to be checked. ' are gone. Can´t wait for the release.
Try this: fetch -xvf tevent-0.9.31.tar.gzcd tevent-0.9.31./configuremake installand then try building that branch again.I also had issues with the FreeBSD versions of TDB and talloc. Grab the latest from here and do the same as above. AndRemember to./configure in the samba folder before trying again.I had issues with smbtorture compiling. It was complaining about undefined reference to ldbunpackdataonlyattrlistflags``. To solve that problem (since I didn't care about smbtorture and didn't know how to prevent it from being compiled I just edited source4/torture/ldb/ldb.c and replaced every reference to `ldbunpackdataonlyattrlistflags(blah blah blah)` with a `0`. This will probably break things horribly when using smbtorture so I wouldn't recommend this as a proper fix. Couldn't get it to work.
Samba also seems to be using a bundled tdb and talloc, and forcing it to use non-bundled libraries causes the configure script to fail: #./configure -bundled-libraries=NONE.Checking for system tdb = 1.3.11: not foundERROR: System library tdb of version 1.3.11 not found, and bundling disabled.This occurs when tdb 1.3.11 has been manually installed into /usr/local.Could you provide how you got the branch to successfully compile on FreeBSD, or provide a disk image of a FreeBSD system where successful compilation is possible? My permissions were largely related to my use of docker as a deployment choice. Nothing specific to time machine.What I ended up with was a docker container that had a /timemachine vol mount from the host, which was owned by backup:backup. I created a smbpasswd user backup inside the container. I also have a container startup script that ensure's /timemachine is chown'd to the backup user inside the container. Since both the host and the container base image are ubuntu:16.04, they each have a matching backup user with same uid.Initially I tried to force user = nobody in the timemachine with the /timemachine vol also being owned by nobody but I could not get this to work.
This may have been a function of samba that I am just not aware of, though.My dockerfile is -. With some other notes about usage in the readme. I’ve followed your steps and was able to successfully compile and install Samba from your branch on my FreeBSD 11 system.Samba is now installed to /usr/local/samba and expects its config file at /usr/local/samba/etc/smb.conf.
I’ve put the following file there: globalserver string = Fileserversecurity = userpassdb backend = tdbsamdurable handles = yeskernel oplocks = nokernel share modes = noposix locking = nofruit:advertisefullsync = truetimemachinepath = /tank/timemachinebrowseable = yesvfs objects = catia fruit streamsxattrfruit:aapl = yesread only = noinherit acls = yesI’ve then started nmbd and smbd: /usr/local/samba/sbin/nmbd -d3/usr/local/samba/sbin/smbd -d3When I try connect from my Mac to smb://10.0.2.166/timemachine, I get the message There was a problem connecting to the server “10.0.2.166”. Can I chip in into this? I'd like to see a small modificationsI'd like it to be able to set the maximum size of the backup in a vfs:fruit attribute. This same functionality was available in netatalk, and I also don't think it's a quota - I have a osx server instance, and Finder (and the TM prefpane intially) report the full size of the drive, but when starting a backup, TM obeys the max size limit set in osx server properties for timemachine. I wouldn't begin to know what magic bits they use to signal that, but I can provide pcaps, and maybe the netatalk authors know something too.This makes it unnecessary to use hacks like creating a loopback-mounted filesystem just to limit backup size (which can grown to fill the whole hdd if left to its own devices).
![]() Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2023
Categories |