diff --git a/CHANGELOG b/CHANGELOG
index 4fd7d03eb3..0f5909e6e9 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -30,6 +30,10 @@ git-annex (6.20170102) UNRELEASED; urgency=medium
   * Fix build with aws 0.16. Thanks, aristidb.
   * assistant: Make --autostart --foreground wait for the children it
     starts. Before, the --foreground was ignored when autostarting.
+  * initremote: When a uuid= parameter is passed, use the specified
+    UUID for the new special remote, instead of generating a UUID.
+    This can be useful in some situations, eg when the same data can be
+    accessed via two different special remote backends.
 
  -- Joey Hess <id@joeyh.name>  Fri, 06 Jan 2017 15:22:06 -0400
 
diff --git a/Command/InitRemote.hs b/Command/InitRemote.hs
index 4a89bed7cf..78a1738d55 100644
--- a/Command/InitRemote.hs
+++ b/Command/InitRemote.hs
@@ -46,8 +46,14 @@ start (name:ws) = ifM (isJust <$> findExisting name)
 
 perform :: RemoteType -> String -> R.RemoteConfig -> CommandPerform
 perform t name c = do
-	(c', u) <- R.setup t R.Init Nothing Nothing c def
+	(c', u) <- R.setup t R.Init cu Nothing c def
 	next $ cleanup u name c'
+  where
+	cu = case M.lookup "uuid" c of
+		Just s
+			| isUUID s -> Just (toUUID s)
+			| otherwise -> giveup "invalid uuid"
+		Nothing -> Nothing
 
 cleanup :: UUID -> String -> R.RemoteConfig -> CommandCleanup
 cleanup u name c = do
diff --git a/doc/git-annex-initremote.mdwn b/doc/git-annex-initremote.mdwn
index 1b46ff5363..d47c66506d 100644
--- a/doc/git-annex-initremote.mdwn
+++ b/doc/git-annex-initremote.mdwn
@@ -33,6 +33,12 @@ is run in a new clone, it will attempt to enable the special remote. Of
 course, this works best when the special remote does not need anything
 special to be done to get it enabled.
 
+Normally, git-annex generates a new UUID for the new special remote.
+If you want to, you can specify a UUID for it to use, by passing a
+uuid=whatever parameter. This can be useful in some situations, eg when the
+same data can be accessed via two different special remote backends.
+But if in doubt, don't do this.
+
 # OPTIONS
 
 * `--fast`
diff --git a/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_2_8ace9ec8cb5264fd424b3bc550d96ba5._comment b/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_2_8ace9ec8cb5264fd424b3bc550d96ba5._comment
new file mode 100644
index 0000000000..fc22f0c904
--- /dev/null
+++ b/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_2_8ace9ec8cb5264fd424b3bc550d96ba5._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-02-07T18:59:41Z"
+ content="""
+I've made `initremote` be able to be provided with a uuid=whatever
+parameter to use whatever UUID you like.
+
+Valid use cases include setting up two special remotes that access the same
+data store through two different interfaces. For example, a rsync special
+remote that is also accessible via a NFS mount as a directory special remote.
+
+It can also be used when two unrelated repositories want to use the same
+data store. Of course, dropping data from the data store then becomes a
+problem, since one of the repositories will know it was dropped, and the
+other one won't. Can get into situations where one of the repositories
+was relying on its remote as the only place a file was stored, and so loses
+the only copy it knows about when the other repository moves the content
+from the remote.
+
+For datalad-archives, I think dropping content from that special remote is
+not supported. Which nearly avoids such problems. If so, it should be fine
+to reuse some UUID for all the datalad-archives special remotes in
+different unrelated datalad repositories.
+"""]]