Our file share seems to be running well now, except for one bothersome thing; The generation of hidden system files. I noticed this after one of our team members accessed our Samba share from a system running Mac OS, where I could see where he’d looked around by the trail of hidden ._.DS_Store files he had left behind.
Users who access the Samba shares from a Mac will inadvertently generate ._.DS_Store and .DS_Store files that are just plain annoying. Although you can view them if you have the option to view hidden files turned on, by default they’re hidden and make an apparently empty directory NOT empty, amongst other annoyances. This is even true from within Linux, where listing a directory with one of these rogue files shows nothing:
But you’ll be able to see hidden files, with the -a switch.
And finally you can see more about the files with both -l and -a.
So how do you stop this from happening?
Samba allows you to “veto files” by specifying which files in the current folder you want to remove – but this doesn’t actually get rid of them on its own. Since Samba builds on top underlying permissions in the Unix system, all that this does is to hide these files from the view of Windows share users.
This is quite annoying – because if you try and delete a folder, it just won’t let you (and, at least on my Windows 8 system, no error shows up). You have to also specify “delete veto files = yes” to allow users to delete these files too (even if you can’t see them). Open up the Samba configuration (etc/samba/smb.conf) and, under your share name, add the following two lines:
However, this doesn’t get rid of files that already exist; it just hides them. I think many people think that this is enough – but I’d really like to avoid the creation of residual files and hidden behaviours like this in the first place, so I wanted to find a more robust solution.
The most popular articles exist suggest that the above two lines should be enough. Actually, it has been suggested to add all ._* files to this list on some of these articles – but this can affect some unix files too, which isn’t necessarily what we want to have happen.
But it turns out that these two lines are probably the best approach – and what wasn’t initially clear, too, is that this does actually stop files from being created in the first place. You can test this out by doing something like copying over just a plain text file called “hello.txt”, which should be blacklisted in the veto files list:
Now, the message you get is that it can’t find it in the source folder, but all that is happening is that it just isn’t copying it over. Don’t worry, it isn’t deleting the original file!
This should be all you need to do – but one other thing that should be pointed out is the format that Samba expects you to have files listed in, if you’re trying to veto multiple files. Each file should be separated by a forward slash with no spaces, like so:
/test1.txt/test.txt/test3.txt
Well, actually.. you can have spaces.. but in that case, it has to look like this:
/test1.txt/ /test2.txt/ /test3.txt/
If you do the following, then only test3.txt is removed, since the space is included in the name of the file:
/test1.txt /test.txt /test3.txt
This is important – since if a file has a space in the name, you would NOT use quotes as you might expect you’d have to; you simply write the name as it appears:
/test 1.txt/test 2.txt/test 3.txt
The last thing to do now is to cleanup the files that already exist. Since there could be any number of folders and subfolders that have been accessed by a Mac user, you need to do a recursive search for the files and then delete them.
find . -name "*DS_Store" -delete
(You can replace the *DS_Store part with anything you want to find and delete, for example .DS_Store, ._.DS_Store, desktop.ini or thumbs.db)
As a final thought is that, there is a possibility that this has an effect the server’s performance when writing files since it has to check the list of veto’d files every time a file is written. This is not a critical issue for shared drives where read time is often more important than write time, but its a consideration for the future if performance was ever to be of critical importance.
No comments:
Post a Comment