diff --git a/Annex/Content.hs b/Annex/Content.hs
index ea01189e4d..502e9fa274 100644
--- a/Annex/Content.hs
+++ b/Annex/Content.hs
@@ -456,7 +456,7 @@ withTmp key action = do
  -
  - When a key has associated pointer files, the object is hard
  - linked (or copied) to the files, and the object file is left thawed.
- 
+ - 
  - In direct mode, moves the object file to the associated file, or files.
  -
  - What if the key there already has content? This could happen for
@@ -564,11 +564,12 @@ data FromTo = From | To
 {- Hard links or copies from or to the annex object location. 
  - Updates inode cache.
  -
- - Thaws the file that is not the annex object.
- - When a hard link was made, this necessarily thaws
- - the annex object too. So, adding an object to the annex this
- - way can prevent losing the content if the source file
- - is deleted, but does not guard against modifications.
+ - Freezes or thaws the destination appropriately.
+ -
+ - When a hard link is made, the annex object necessarily has to be thawed
+ - too. So, adding an object to the annex with a hard link can prevent
+ - losing the content if the source file is deleted, but does not
+ - guard against modifications.
  -
  - Nothing is done if the destination file already exists.
  -}
@@ -584,9 +585,12 @@ linkAnnex fromto key src (Just srcic) dest destmode =
 			return LinkAnnexNoop
 		Nothing -> ifM (linkOrCopy key src dest destmode)
 			( do
-				thawContent $ case fromto of
-					From -> dest
-					To -> src
+				case fromto of
+					From -> thawContent dest
+					To -> do
+						s <- liftIO $ getFileStatus dest
+						unless (linkCount s > 1) $
+							freezeContent dest
 				checksrcunchanged
 			, failed
 			)
diff --git a/CHANGELOG b/CHANGELOG
index b26a0b0e85..b4d9905c53 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -19,6 +19,8 @@ git-annex (6.20180808) UNRELEASED; urgency=medium
   * v6: Update associated files database when git has staged changes
     to pointer files.
   * v6: Fix some race conditions.
+  * v6: Fix annex object file permissions when git-annex add is run
+    on a modified unlocked file, and in some related cases.
   * Fix git command queue to be concurrency safe.
   * linux standalone: When LOCPATH is already set, use it instead of the
     bundled locales. It can be set to an empty string to use the system
diff --git a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded.mdwn b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded.mdwn
index a8f0f3b407..a7c01972b2 100644
--- a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded.mdwn
+++ b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded.mdwn
@@ -31,3 +31,5 @@ Debian Stretch, but building git-annex from source with `stack build`.
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Yes, everyday.  Thank you for git-annex :-)
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_6_2d3e926459c04c6a9a2c5a43ee9733e4._comment b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_6_2d3e926459c04c6a9a2c5a43ee9733e4._comment
new file mode 100644
index 0000000000..3db37eee6b
--- /dev/null
+++ b/doc/bugs/v6__58___write_permission_on_annex_object_if_unlocked__44___modified__44___and_readded/comment_6_2d3e926459c04c6a9a2c5a43ee9733e4._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2018-09-05T18:26:33Z"
+ content="""
+Reproduced.
+
+Analysis: In v6, `git annex add` runs `git ls-files --modified`, 
+which runs the clean filter on the unlocked file as git sees it was
+modified. Which in ingests the file with lockingFile = False.
+So, the annex object doesn't get the write bit cleared at that point.
+Then when `git annex add` gets around to ingesting the file
+itself, since the annex object is already present it's used as-is.
+
+`git add` of a new file in v6 also puts content in the annex
+with the write bit set. If a different file with that same content is then passed
+to `git annex add`, the same thing happens with the symlink to unprotected
+content.
+
+So, linkToAnnex should freezeContent. That would solve all cases that lead
+to this. (But not when annex.thin has made the annex object a hard link,
+in that case it being writable is expected.)
+"""]]