Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using Samba 2:3.5.4 in Ubuntu 10.10 Server, and an EXT4 filesystem.

I have setup a folder "dev" locally on my pc, and using "cp -alf" hard linked that folder, to folder "test". So upon looking in the "test" folder it has exactly the same contents as the "dev" folder.

"test" is currently shared using Samba on the network.

If I change a file in "test" on the local file system. The change is reflected in the "dev" folder (as the folders are linked). This is as expected.

When a file in "test" is modified via a Samba share, the hard link is broken. Ie, the change will only apply to "test" and not to "dev".

Modifying files via Samba, and it breaking the hard links is actually what we want. What I've been asked (and I can't find any white papers on it), is this:

  • a bug
  • or as designed

The danger is, that if it is a bug, and we start using the above solution, when the bug gets fixed our setup will no longer work!

Anyone got any ideas,


share|improve this question

I can't comment on Samba specifically, but often the particular application in use is responsible for breaking the links. Some editors, for example, replace a file -- instead of simply overwriting it -- when saving changes, which of course would break any hard links associated with the, your behavior may be due more to the application you're using than to Samba.

share|improve this answer
True, I guess it will be Samba breaking the link in that case. Maybe a modification is treated as a new file. Just need to prove that's as designed now... – Bealer Jan 22 '11 at 10:27

This is not samba behavior that breaks the link. Larsks is correct that the behavior you described is application specific. Applications will write to files using two basic methods: Method "A": simply write back to the original file. Method "B": follow a safe algorithm: (1) write to temp-file; (2) if successful temp-file write then replace orig-file with temp-file. In Method "B" the write to temp-file will of course result in a new inode and the replacement of orig-file breaks the hard link.

See this for yourself: create a simple text.txt file on the samba share along with a corresponding hard linked file. Edit the samba file using notepad or wordpad and you will see the inodes are still the same. Do the same think using MS-Word and find the saved file gets a new inode, thus breaking the hard link. So notepad and wordpad use Method "A" while MS-Word uses Method "B". You can further prove to yourself this is not samba by using a local ext3 file system mounted in windows and running the same tests.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.