How to stop .DS_STORE files and ._ files being created in shares (SERVER SIDE)


Recommended Posts

Hi Guys

 

I was fed up with when i went onto a share with my mac, or osx vm, the ._ files  (appledouble files that are used to store metadata) and .DS_STORE files being created in my shares.

 

I saw various tweaks to do with my mac that were meant to stop it writing these hidden files on the shares, but they didnt work for me.

Also if another mac came onto the system it would just do the same, so client side wasnt the best option.

 

So i thought the best solution would be to stop UNraid from being able to show these files so here is how

 

Goto settings, then smb .

Then under samba extra configuration add this line

 

veto files = /._*/.DS_Store/

 

This then stops ._  and .DS_Store files from being able to be seen at all by adding it to the  smb-extra.conf file.

 

samba.png

 

You will need to stop the array and restart it for this change to take effect.

 

Hope this is useful for you guys  :)

 

 

 

 

  • Upvote 2
Link to comment

Since you are an OS X user, why do you want to remove (or, rather, prevent the creation of) these files? They actually do serve a purpose with OS X and you can hide them, along with all other .* files, if they clutter up any Windows Explorer windows. If you do suppress their creation then you are not copying every aspect of the original file, which seems like a bad thing to me. If by default they weren't created I would be making a feature request to enable them.

Link to comment

Hi...

 

Nice thought as this also has bugged me.

 

I however do not have such an area in that area.  Just have Enable SMB, Hide "dot" files and then a workgroup section.  There is no SMB Extras area.

 

What version of UnRAID are you running on?

 

 

Version 6.1.9  - Shows as current.

Link to comment

Hi...

 

Nice thought as this also has bugged me.

 

I however do not have such an area in that area.  Just have Enable SMB, Hide "dot" files and then a workgroup section.  There is no SMB Extras area.

 

What version of UnRAID are you running on?

 

 

Version 6.1.9  - Shows as current.

 

Sorry forgot to say running UNraid 6.2 23 beta.

Link to comment

Since you are an OS X user, why do you want to remove (or, rather, prevent the creation of) these files? They actually do serve a purpose with OS X and you can hide them, along with all other .* files, if they clutter up any Windows Explorer windows. If you do suppress their creation then you are not copying every aspect of the original file, which seems like a bad thing to me. If by default they weren't created I would be making a feature request to enable them.

 

The problem is when an OS X (or is it macOS now?) user comes onto the shares, the Windows users see those ._ files and .DS_Store files anyway and it is super annoying when it clutters it up. And anyway, DS_Store files are there to speed up Spotlight searches (I believe) and does no harm when deleted. It just means that server-side files won't get indexed, which is a enhancement, because it improves security.

 

These ._ files  basically  contain anything that the Mac OS X file system supports but the file system of your unraid share  does not. It is written as 2 files. When you copy the file back to OS X, the data and resource fork info is combined again into a normal Mac file.

 

Most of the time, removing these is no big deal. They hold simple data like type and creator codes, modification dates, icons, etc. Yes there are times when they contain more such as mac legacy TrueType fonts(They store the font data in the resource fork) but this is rare.

Anyway some people may like to prevent certain files being created on the share. If you only wanted to prevent one type of file and not the other you can just edit the smb config for that one you want stopped.

 

I use an osx laptop to access my unraid but i also have windows and linux on my system aswell from which  i see these  ._ files.

 

For example

folders.png

 

You can see the file petst.exe  which was a file i downloaded on my mac and put into a share for my windows vms to access.

Because i downloaded it on the mac it added this file when i copied it to the share. Obviously a mac ._ file is not needed for the .exe file on windows.

At times i may have downloaded 20 files on the mac for use on windows then i have a folder full of ._ files with the same name and its just confusing. I have even copied a file off the share onto a usb stick to take somewhere to only find it the damn ._ file and not the correct file..... but thats probably me just being careless!

 

 

Link to comment

Since you are an OS X user, why do you want to remove (or, rather, prevent the creation of) these files? They actually do serve a purpose with OS X and you can hide them, along with all other .* files, if they clutter up any Windows Explorer windows. If you do suppress their creation then you are not copying every aspect of the original file, which seems like a bad thing to me. If by default they weren't created I would be making a feature request to enable them.

 

The problem is when an OS X (or is it macOS now?) user comes onto the shares, the Windows users see those ._ files and .DS_Store files anyway and it is super annoying when it clutters it up. And anyway, DS_Store files are there to speed up Spotlight searches (I believe) and does no harm when deleted. It just means that server-side files won't get indexed, which is a enhancement, because it improves security.

 

The DS in .DS_Store stands for Desktop Services and have nothing to do with Spotlight indexing. The files contain information about the enclosing folder, such as icon size and layout, scroll-bar position, window background, etc. All these are irrelevant to Windows users but they are used by the OS X Finder to keep its view on the folder consistent. They provide part of the look and feel of the system so I, for one, would not care to lose them.

 

The ._ files are described above and they are also where extended attributes are stored. Again, as a mostly Mac user, I wouldn't want to lose them.

 

You can hide all "hidden" dot-files from Windows users.

 

Link to comment

I, for one, would not care to lose them.

 

The ._ files are described above and they are also where extended attributes are stored. Again, as a mostly Mac user, I wouldn't want to lose them.

 

You can hide all "hidden" dot-files from Windows users.

 

So now Mac users have a choice. Thanks gridrunner. I've been manually deleting the ._ files once a week for months now. Any differences this has caused must be minor. I haven't noticed any difference between share windows and local folder windows. I'll be glad when a stable version of unRaid 6.2 is released so that I can incorporate this.

Link to comment

I, for one, would not care to lose them.

 

The ._ files are described above and they are also where extended attributes are stored. Again, as a mostly Mac user, I wouldn't want to lose them.

 

You can hide all "hidden" dot-files from Windows users.

 

So now Mac users have a choice. Thanks gridrunner. I've been manually deleting the ._ files once a week for months now. Any differences this has caused must be minor. I haven't noticed any difference between share windows and local folder windows. I'll be glad when a stable version of unRaid 6.2 is released so that I can incorporate this.

 

You dont need to use 6.2 beta, its just easier using the gui. You can edit your smb-extra.conf file manually aswell.

It is in your flash drive under

 

config/

smb-extra.conf

 

Use a text editor and add it here and you should be good to go.

 

edit ..........

 

if you dont see the smb-extra.conf you can add it yourself or just install unassigned device plugin as it uses the smb-extra.conf file to add the unassigned devices in as shares and after mounting and sharing a device you will see it creates this file.

 

Link to comment

You dont need to use 6.2 beta, its just easier using the gui. You can edit your smb-extra.conf file manually aswell.

It is in your flash drive under

 

config/

smb-extra.conf

 

Use a text editor and add it here and you should be good to go.

 

edit ..........

 

if you dont see the smb-extra.conf you can add it yourself or just install unassigned device plugin as it uses the smb-extra.conf file to add the unassigned devices in as shares and after mounting and sharing a device you will see it creates this file.

 

Same code?

Link to comment

You dont need to use 6.2 beta, its just easier using the gui. You can edit your smb-extra.conf file manually aswell.

It is in your flash drive under

 

config/

smb-extra.conf

 

Use a text editor and add it here and you should be good to go.

 

edit ..........

 

if you dont see the smb-extra.conf you can add it yourself or just install unassigned device plugin as it uses the smb-extra.conf file to add the unassigned devices in as shares and after mounting and sharing a device you will see it creates this file.

 

Same code?

 

yes just add

 

for both ._ files and .DS_Store files

 

veto files = /._*/.DS_Store/

 

or for only .DS_Store files

 

veto files = /.DS_Store/

 

or only ._ files

 

veto files = /._*/

 

 

 

 

Link to comment

I get it I think. The veto doesn't stop the file being written, just tells the samba browser to ignore the file. Right? And delete veto will allow deleting folders that contain vetoed files?

 

It tells the samba server to deny the file's existence. See here: https://www.samba.org/samba/docs/using_samba/ch08.html

 

That's fine if your Windows computers are connecting via SMB and your Macs are connecting via AFP, but with modern versions of OS X SMB is being used more and more, so the Macs are also being denied access to the ._ files. The hide option is a much better one in that case.

 

Link to comment

I get it I think. The veto doesn't stop the file being written, just tells the samba browser to ignore the file. Right? And delete veto will allow deleting folders that contain vetoed files?

 

It tells the samba server to deny the file's existence. See here: https://www.samba.org/samba/docs/using_samba/ch08.html

 

That's fine if your Windows computers are connecting via SMB and your Macs are connecting via AFP, but with modern versions of OS X SMB is being used more and more, so the Macs are also being denied access to the ._ files. The hide option is a much better one in that case.

 

But is there an option to delete hide files? I'm not a samba wizard, but it looks like if you use "hide" instead of "veto" you wouldn't be able to delete the hidden files when deleting the folder.

Link to comment

No, there doesn't appear to be that option. But is that because it isn't needed? Vetoed files prevent deletion of the parent directory unless the "delete veto files" option is set to "yes" but do hidden files prevent deletion of the parent directory ever?

 

It's all a question of what you want to achieve. The reason behind the veto option was to hide the ._ files from Windows users in order to prevent them from deleting the files because they were important to Mac users. That was useful when Windows used SMB and Macs used AFP. If both operating systems now use the same protocol but there are different requirements then there's clearly a conflict.

 

I use the hide option myself and my Macs connect to unRAID via AFP, with SMB only being used by the occasional Windows client, so it works for me. Perhaps a better option for other people might be to configure OS X not to create the ._ files on network volumes in the first place.

 

Link to comment

Doesn't this create a problem for you when you try to delete shares that are no longer needed? I always have to go hunting for DS files.

 

I have no problem deleting folders from OS X's Finder, whatever their contents. I don't use Windows so much these days but I don't recall having any problems there either. That's the difference between the hide and veto options. Hide just makes the dot files invisible to SMB users - it doesn't prevent them being deleted when the parent folder is deleted (assuming their permissions are the same as those of their associated data fork file, which I believe is always the case).

 

Link to comment

I get it I think. The veto doesn't stop the file being written, just tells the samba browser to ignore the file. Right? And delete veto will allow deleting folders that contain vetoed files?

 

It tells the samba server to deny the file's existence. See here: https://www.samba.org/samba/docs/using_samba/ch08.html

 

That's fine if your Windows computers are connecting via SMB and your Macs are connecting via AFP, but with modern versions of OS X SMB is being used more and more, so the Macs are also being denied access to the ._ files. The hide option is a much better one in that case.

 

John_M I think you are right the hide option is a better option where the mac needs to access shares with these files, when they are needed.

(However I personally dont like seeing the files at all. I have my windows machines usually with the show hidden files checked so i see the files anyway with the hide option. I also dont like to see the files when working in krusader docker.)

 

The thing i like about the veto is it hides all the existing "veto" files but also stops new files of this type even being created.

However this is where the deleting folders problem can occur with these hidden files in.

If you had a folder that already had veto files in it, then you applied the veto then these files would not be visable but still present.

So here is where you would need to add the delete veto files = yes. (This isnt necessary if you had no files of this type in the first place as none would be created.)

 

I see the best of both worlds to be to do something like the following, mixing the hide and veto options together.

 

For example

 

hide files = /._*/.DS_Store/

[media]
path =/mnt/user/Media
veto files = /._*/.DS_Store/

[softwarewin]
path =/mnt/user/softwarewin
veto files = /._*/.DS_Store/

 

Here you are first globally hiding the ._* and  .DS_Store files. So they are still available to macs.

 

However the other 2 sections veto the ._* and  .DS_Store files  in the shares called [softwarewin]  and [media]

Obviously your media folder doesnt need these file types so its worth excluding them from this individual share. Same goes for the software windows share.

 

Using both you can have shares that keep these files but arent seen by windows (hide) and other shares where these files cant be created or seen(veto).

 

People need to  test and find out what works best for their situation.

 

  • Upvote 1
Link to comment

(However I personally dont like seeing the files at all. I have my windows machines usually with the show hidden files checked so i see the files anyway with the hide option. I also dont like to see the files when working in krusader docker.)

 

If Samba is set up to hide the dot files but Windows is set to display them, they should appear greyed out. But I find it puzzling that you have Windows set to display hidden files when you don't like seeing them!

 

I use the Krusader docker too and like it because it tells the truth - I don't like files that are present being hidden from me.

 

I'm fundamentally opposed to a file server that is configured to ignore requests to create files with certain names, preferring the option of configuring the clients so they don't make the requests in the first place, but I'm pleased you have found a solution that works for you and maybe other people will find it useful too.

 

Link to comment
  • 2 years later...
On 6/24/2016 at 8:22 AM, ideaman924 said:

Guess the SMB options only show up on beta versions.

 

BTW, I'm on v6 21. Hope to upgrade to 23... maybe.

In case any new users stumble upon this thread. The option to hide .DS_Store files is available in the GUI.

Settings > Network Settings > SMB > Hide "dot" files

On 6/26/2016 at 8:47 AM, John_M said:

Perhaps a better option for other people might be to configure OS X not to create the ._ files on network volumes in the first place.

 

I ran the terminal command (I don't remember it off the top of my head), rebooted the computer, but the files are still being made on the array.

From my understanding, Apple is slowly phasing out AFP and SAMBA will be the way to go; sticking with SAMBA for now.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.