Jump to content
SpaceInvaderOne

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

31 posts in this topic Last Reply

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  :)

 

 

 

 

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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!

 

 

Share this post


Link to post

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.

 

Share this post


Link to post

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.

Share this post


Link to post

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.

 

Share this post


Link to post

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?

Share this post


Link to post

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 = /._*/

 

 

 

 

Share this post


Link to post

I block a few more items than this, but similar:

veto files = /._*/.DS_Store/.AppleDouble/.Trashes/.TemporaryItems/.Spotlight-V100/
delete veto files = yes

Share this post


Link to post

If delete veto files is set to yes, the user can delete both the regular files and the vetoed files in the directory, and the directory itself is removed. If the option is set to no, the user cannot delete the vetoed files, and consequently the directory is not deleted either.

Share this post


Link to post

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?

Share this post


Link to post

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.

 

Share this post


Link to post

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.

Share this post


Link to post

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.

 

Share this post


Link to post

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.

Share this post


Link to post

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).

 

Share this post


Link to post

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.

 

Share this post


Link to post

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.