You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/storage-mover/endpoint-manage.md
+19-2Lines changed: 19 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -74,9 +74,11 @@ There are many use cases that require preserving metadata values such as file an
74
74
75
75
### NFS endpoints
76
76
77
-
Using the NFS protocol, you can transfer files between computers running Windows and other non-Windows operating systems, such as Linux or UNIX. The current Azure Storage Mover release supports migrations from NFS shares on a NAS or server device within your network to an Azure blob container only.
77
+
Using the NFS protocol, you can transfer files between computers running Windows and other non-Windows operating systems, such as Linux or UNIX. Azure Storage Mover release supports migrations from NFS shares on a NAS or server device within your network to an Azure blob container or Azure file shares.
78
78
79
-
Unlike SMB, NFS doesn't utilize the ACL concept or user-based authentication. This difference allows NFS endpoints to be accessed without Azure Key Vault integration. In addition, Storage Mover processes metadata differently for both NFS mount sources and their blob container target counterparts. The following table identifies outcomes for common metadata encountered during migration:
79
+
Unlike SMB, NFS doesn't utilize the ACL concept or user-based authentication. This difference allows NFS endpoints to be accessed without Azure Key Vault integration.
80
+
81
+
Storage Mover processes metadata differently for both NFS mount sources and their blob container target counterparts. The following table identifies outcomes for common metadata encountered during migration:
@@ -89,6 +91,21 @@ Unlike SMB, NFS doesn't utilize the ACL concept or user-based authentication. Th
89
91
|Last accessed timestamp|This timestamp is preserved as custom blob metadata if it exists on the source file. There's no blob-native timestamp of this type.|
90
92
|Other metadata |Other metadata is persisted in a custom metadata field of the target blob if it exists on source items. Only 4 KiB of metadata can be stored. Metadata of a larger size isn't migrated.|
91
93
94
+
For NFS mount sources and Azure File share targets, the following table identifies outcomes for common metadata encountered during migration:
|Directory structure |The original directory structure of the source will be preserved on the target share.|
99
+
|Access permissions |Access mode, user and group permissions will be preserved from source file or directory on the target share.|
100
+
|Symbolic links |Symbolic links are skipped.|
101
+
|Hard links |Target file will be copied as regular file. Files on the source which are hard links will not be linked at the destination. The destination will receive full copies despite hard link status at the source.|
102
+
|Create timestamp |The original create timestamp of the source file will be preserved on the target share.|
103
+
|Change timestamp |Not preserved. NFS semantics treat ctime as a read-only attribute.|
104
+
|Modified timestamp |The original modified timestamp of the source file will be preserved on the target share.In some cases where directory information is updated before the files are updated, the “Modified timestamp” on directory will be reflected correctly after first sync and not during the initial copy.|
105
+
|Last accessed timestamp|Not preserved. This last access timestamp is neither supported for a file nor a directory on the target share.|
106
+
107
+
108
+
92
109
## Create an endpoint
93
110
94
111
Before you can create a job definition, you need to create endpoints for your source and target data sources.
0 commit comments