Time Machine support option frags permissions to copy/delete on all OMV SMB shares

Zitat von Headsails

Background: All was working fine on OMV regarding SMB files shares with both Mac (Monterey) and Windows 11 machines but for some unknown reason quit working on the Mac. The error on Mac was due to permissions and would not let me copy folders from the Mac to any OMV SMB share. It would however place a folder in the share like it wanted to copy but was empty and subsequently would not delete for the same permissions issue. Nonetheless, I was allowed to copy "files" over to OMV shares from the Mac and could delete them as well. But "folders" had the permission issues. After much testing and research into permissions tricks (non terminal) using the OMV GUI (i.e. reset perms), I could get the fold to copy once but after that the issue came back with the need to use reset perms again.

Eventually, I removed all users from the OMV system and removed all SMB shares. I rebuilt the users and SMB file shares and all worked again. However, I knew there was one share that was allotted to the Time Machine support that would need to be enabled, so I enabled it and the problem came back exactly the same as before. Funny thing though is Time Machine had no problems running its backup to the shared SMB folder on OMV while this permissions thing was going on for everything else.

So, I disable Time Machine support and all is working again but without Time Machine support. My assumption now is that Time Machine support for one of the SMB shares was enough to screw up all the permissions for the rest of the shared folder on OMV. I'm not sure why and would like to know if someone can help get Time Machine support to work without messing up the permission on all other SMB shares that are not touched by Time Machine? Do I turn on Time Machine support on all my SMB shares regardless of needing it for Time Machine (probably no?)? I have 10 other ways of backing up my Mac but Time Machine seems kind of cool and was working OK previously (seemingly nothing changed except one weird issue where I couldn't access the OMV GUI and had to reboot OMV from the console. After that seems like when the problem started).

Thank you for this post. I had the same problem with my MacbookPro and Mac mini (both macOS Monterey installed). I couldn't copy any single file to the server because of "permission issues". I have searched the whole internet day by day to solve this matter. Yesterday I found your post and after disabling "Time Machine" on my OMV (v6) server, everything works like it should.

Now I have to find out why? Why does "time machine" has such an impact at "write permissions" on the server?

Is there anybody who has the same problem and could solve it?

i had same problem from ipad using files app.

1. cant save files to samba share

2. enable time machine, now its working can save files

3. had problem with omv os so I install new (omv6). enable samba & time machine

4. back to problem cant save from iPad, remove files app and reinstall. same. made new user also same problem

5. on windows 10 I have no problem

6. update* install reset permsission plugin and reset shared folder permission. save working. I guess that did it for me

I struggled with the weirdest permission issues when I created files on Samba shares from MacOS. I have entered this option in the SMB/CIFS config options and this seems to have fixed my problem:

fruit:nfs_aces = no

You can find more information at the very bottom of the following page: https://wiki.samba.org/index.p…Work_Better_with_Mac_OS_X.

Just try and see if this helps. You probably have to do a reset share folder permission first.

Had the same problem with Monterey 12.5

To solve it:
1 Use the reset permission plugin on your shares (you can install it from the plugin panel)

2 Put the code in the smb configuration page (under extra options)

fruit:nfs_aces = no

3 If you also want to use TimeMachine, since it breaks the smb shares for macOS, DON'T tick the option in the samba share, but put the following code in the "extra options" of the samba share you want to use for the backups (see attached image)

vfs objects = fruit streams_xattr
fruit:time machine = yes

Using these settings it finally works for me as it should and I can use both TimeMachine and the samba shares.

I suspect there is something wrong with omv default implementation of timemachine\smb

Also, I have found the link in the previous post to be quite helpful

When you select "Time Machine Support" on an SMB/CIFS Share the following additional lines are added to that shares configuration in the /etc/samba/smb.conf:

fruit:encoding = private
fruit:locking = none
fruit:metadata = stream
fruit:resource = file
fruit:veto_appledouble = no
fruit:nfs_aces = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
fruit:time machine = yes

AND

it changes the share's configuration from

vfs objects =

to

vfs objects = fruit streams_xattr

The issue is that ALL OTHER SMB/CIFS shares also change from:

vfs objects =

to

vfs objects = fruit streams_xattr

AND for me setting the share to "fruit streams_xattr" is what cause the folder issue with MacOS Monterey.

So building on that knowledge and experimentation, as long as you don't tick the "Time Machine Support" option on any share and your "vfs objects" are not changed to "fruit stream_xattr" the folder issue is not present.

I want Time Machine Support so I just tried to add the following to the extras of my time machine share while not ticking the "Time Machine Support"

vfs objects =  fruit streams_xattr
fruit:encoding = private
fruit:locking = none
fruit:metadata = stream
fruit:resource = file
fruit:veto_appledouble = no
fruit:nfs_aces = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
fruit:time machine = yes

This essentially makes any share a time machine share without impacting the other smb shares in smb.conf BUT

There is now a problem avahi deamon (the disovery service) configuration.

If you don't check any share as "Time Machine Support" the /etc/avahi/services/smb.service looks like this:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h - SMB/CIFS</name>
<service>
<type>_smb._tcp</type>
<port>445</port>
</service>
</service-group>

We want it to look like this to advertise it as a Time Machine system (but since we have not ticked Time machine support on any share why would it add it to the discovery service):

<?xml version="1.0" standalone="no"?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h - SMB/CIFS</name>
<service>
<type>_smb._tcp</type>
<port>445</port>
</service>
<service>
<type>_adisk._tcp</type>
<txt-record>sys=adVF=0x100</txt-record>
<txt-record>dk0=adVN=timemachine,adVF=0x82</txt-record>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=TimeCapsule</txt-record>
</service>
</service-group>

Both samba's smb.conf and avahi's smb.service configuration files are managed by OMV so you can't hand edit anything. You should use environment variables.

To me, it seems like when you select "Time Machine Support" on an smb share it should do what it does today but it should NOT change the other shares "vfs objects" to "fruit stream_xattr" as well.

I guess the question I have is:

Why are ALL SMB shares either "" or "fruit stream_xattr" for "vfs objects" based on Time Machine Support for just one share?

• I want "vfs objects = " for regular shares and "vfs objects = fruit stream_xattr" for the time machine share.
• I want to be able to tick one share as time machine support so that that it is added to avahi discovery.

Right now, I don't see a way to accomplish both those items.

I might be missing something but this is where I have landed looking at this for a couple of days.

I guess this was done on purpose

https://github.com/openmediavault/openmediavault/issues/727

MacOS is based on BSD, which uses its own permissions, user and group settings. I have often seen macOS create issues on linux based systems (not just OMV) because of the differences in how the systems work.

Since an smb share is controlled by the server, not the workstation, the files have to be written in the server's way of ownership and permissions. This is not OMV specific, but linux servers in general.

In addition to the apple "fruit" options mentioned above, I would also suggest that you add something like the following to the samba share advanced settings, so that all the ownership and permission issues are forced into linux/omv speak instead of left in mac speak (debian/OMV tends to want to create things as root:users or <OMV User Account>:users, while mac wants to do <mac user>:staff or root:wheel, and the mac user, staff and wheel don't exist by default in OMV. Using these settings will keep the files OMV friendly.

create mask = 2777

directory mask = 2777

force create mode = 2777

force directory mode = 2777

force user = <OMV user>

force group = users

You can of course restrict the permissions more as the 777 is full write/read/execute control for owner/group/everyone else, this could easily be dialed back to 775 or 755, but from my experience, I don't go lower when dealing with a mac at the office. I have several systems ranging from Mavericks up to Big Sur, and the samba implementations have been evolving from OS version to version, so to try to maintain compatibility I keep the permissions more open than I normally would if the macs were not in the mix.

Also, from my experience, the samba performance from a mac is horrible. It takes those systems easily 8 to 10 times as long to copy a large video file (large meaning in the 10's of GB) over samba than it takes for a windows or linux system. I attribute it to the fact that apple, in typical apple fashion, has decided to mess with a good working protocol adding that whole "fruit" subset, to make it work better in an apple ecosystem, but in doing so it has been at the expense of severe performance degradation with non-apple systems.

Zitat von votdev

Please use the environment variables feature of OMV to customize the SMB configuration. Only use the xtra options if there is no env variable available. You can use omv-env list to find the SMB related ones, or have a look into https://github.com/openmediava…loy/samba/files/shares.j2.

Because vfs objects = fruit streams_xattr is set globally if only ONE share has time machine enabled it impacts all the other as per my post. There is no environment variable that can solve this that I see. I welcome a specific suggestion based on the behaviors I outlined above. I would love to use an environment variable instead of this hack on Monterey. The problem is the fix for https://github.com/openmediavault/openmediavault/issues/727 that creates this behavior.

Zitat von ryecoaaron

Where do you see streams_xattr being added at the global level? I only see it being added at the share level in the code - https://github.com/openmediava…samba/files/shares.j2#L56

Isn't enable_timemachine_vfs set globally here if time machine is enabled on just one share:

https://github.com/openmediava…oy/samba/20shares.sls#L44

and then ALL smb shares get streams_xattr here based on enable_timemachine_vfs:

https://github.com/openmediava…samba/files/shares.j2#L54

{%- if enable_timemachine_vfs | to_bool %}

{%- set _ = vfs_objects.append('fruit') %}

{%- set _ = vfs_objects.append('streams_xattr') %}

{%- endif %}

I could be missing something. I am just an average user trying to figure this out a while ago.

Zitat von Headsails

Background: All was working fine on OMV regarding SMB files shares with both Mac (Monterey) and Windows 11 machines but for some unknown reason quit working on the Mac. The error on Mac was due to permissions and would not let me copy folders from the Mac to any OMV SMB share. It would however place a folder in the share like it wanted to copy but was empty and subsequently would not delete for the same permissions issue. Nonetheless, I was allowed to copy "files" over to OMV shares from the Mac and could delete them as well. But "folders" had the permission issues. After much testing and research into permissions tricks (non terminal) using the OMV GUI (i.e. reset perms), I could get the fold to copy once but after that the issue came back with the need to use reset perms again.

Eventually, I removed all users from the OMV system and removed all SMB shares. I rebuilt the users and SMB file shares and all worked again. However, I knew there was one share that was allotted to the Time Machine support that would need to be enabled, so I enabled it and the problem came back exactly the same as before. Funny thing though is Time Machine had no problems running its backup to the shared SMB folder on OMV while this permissions thing was going on for everything else.

So, I disable Time Machine support and all is working again but without Time Machine support. My assumption now is that Time Machine support for one of the SMB shares was enough to screw up all the permissions for the rest of the shared folder on OMV. I'm not sure why and would like to know if someone can help get Time Machine support to work without messing up the permission on all other SMB shares that are not touched by Time Machine? Do I turn on Time Machine support on all my SMB shares regardless of needing it for Time Machine (probably no?)? I have 10 other ways of backing up my Mac but Time Machine seems kind of cool and was working OK previously (seemingly nothing changed except one weird issue where I couldn't access the OMV GUI and had to reboot OMV from the console. After that seems like when the problem started).

I had the same problem until I found this post, reset the permissions and disabled Timemachine support.

now everything is working as expected, (except for Timemachine of course ) for now I run a separate HDD For TimeMachine (Mac Mini M1, Mac Mini i7 and my MacBook Air) and wait for a solution.

I'm to much of a beginner to start messing with the system files.

Thanx for this solution.

Zitat von Wrangler

I had the same problem until I found this post, reset the permissions and disabled Timemachine support.

now everything is working as expected, (except for Timemachine of course ) for now I run a separate HDD For TimeMachine (Mac Mini M1, Mac Mini i7 and my MacBook Air) and wait for a solution.

I'm to much of a beginner to start messing with the system files.

Thanx for this solution.

Net-net: The simple hack (until something better is discovered for modern MacOS users) is to re-enable your time machine share and then add "vfs objects = " to the extra options section of every non-timemachine smb share. As you mentioned, this is only needed if you want to run both regular and timemachine smb shares.

Zitat von seanwo

Net-net: The simple hack (until something better is discovered for modern MacOS users) is to re-enable your time machine share and then add "vfs objects = " to the extra options section of every non-timemachine smb share. As you mentioned, this is only needed if you want to run both regular and timemachine smb shares.

Sounds good, but how this is going to effect future updates??

Zitat von Wrangler

Sounds good, but how this is going to effect future updates??

Your mileage may vary. I was simply looking for a workaround for this integration issue. Apple clearly is not following some Windows SMB spec at this point (in later OS versions) and does not care about fixing it. You can find anecdotal evidence of this with a few searches on their forums. The changes to OMV indeed follow a (very old but documented) SMB spec. You have more atomic control over samba config files in a traditional Linux distro making it easily solvable so this makes us (OMV, timemachine, and other samba shares) a rare duck.

Zitat von seanwo

Your mileage may vary. I was simply looking for a workaround for this integration issue. Apple clearly is not following some Windows SMB spec at this point (in later OS versions) and does not care about fixing it. You can find anecdotal evidence of this with a few searches on their forums. The changes to OMV indeed follow a (very old but documented) SMB spec. You have more atomic control over samba config files in a traditional Linux distro making it easily solvable so this makes us (OMV, timemachine, and other samba shares) a rare duck.

Thanx, going to try you're solution.

worst case, I have to start all over