если бы вы не указали -p ( косвенно, через -а), то результат бы был точно как вы хотели:
New files get their “normal” permission bits set to
the source file’s permissions masked with the
receiving directory’s default permissions (either
the receiving process’s umask, or the permissions
specified via the destination directory’s default
ACL), and their special permission bits disabled
except in the case where a new directory inherits a
setgid bit from its parent directory.
полный текст
--perms, -p
This option causes the receiving rsync to set the
destination permissions to be the same as the source
permissions. (See also the --chmod option for a way to
modify what rsync considers to be the source permissions.)
When this option is off, permissions are set as follows:
o Existing files (including updated files) retain
their existing permissions, though the
--executability option might change just the
execute permission for the file.
o New files get their "normal" permission bits set to
the source file's permissions masked with the
receiving directory's default permissions (either
the receiving process's umask, or the permissions
specified via the destination directory's default
ACL), and their special permission bits disabled
except in the case where a new directory inherits a
setgid bit from its parent directory.
Thus, when --perms and --executability are both disabled,
rsync's behavior is the same as that of other file-copy
utilities, such as cp(1) and tar(1).
In summary: to give destination files (both old and new)
the source permissions, use --perms. To give new files
the destination-default permissions (while leaving
existing files unchanged), make sure that the --perms
option is off and use --chmod=ugo=rwX (which ensures that
all non-masked bits get enabled). If you'd care to make
this latter behavior easier to type, you could define a
popt alias for it, such as putting this line in the file
~/.popt (the following defines the -Z option, and includes
--no-g to use the default group of the destination dir):
rsync alias -Z --no-p --no-g --chmod=ugo=rwX
Зависит от реализации демона на виндоусе и как производится копирование - через rsync транспорт или сетевые диски.
Если вы копируете на сетевой диск то права будут такие же как и у соединения. Если через rsync транспорт — то может быть что угодно.
Тут куча ньюансов. Права и владельцы должны действительно быть настроены так чтобы storagenode могла читать и писать файлы, это не значит что владелец должен совпадать. Можно просто дать группе Everyone r/w доступ, и тогда вообще будет неважно кто владелец.
В документации тут написано Storage Node - Storj Docs что можно передать user id и group id через параметр
--user $(id -u):$(id -g)
Тут берется значие текущего пользователя, кто запускает docker run и узел будет запущен от имени этого пользователя. (Это не значит что численное значение id внутри и снаружи контейнера будет одинаковым!)
Теоретически, можно копировать данные как угодно, и потом передать в --user UID и GID владельца файлов. Практически, работоспособность этого будет зависеть от наличия SELinux или AppArmor на машине. Если они запущены, то пространство имен внутри контейнера и хоста разные. Пользователь 313 на хосте может будет соответствовать пользователю 100312 внутри контейнера. Потому так вот назначать права не получится.
Самый надежный способ – это скопировать c какими попало владельцем (или указать владельца через --chown) но дать права читать/писать всем через аргумент --chmod, например, так
rsync -a --chmod=ugo=rwX
Затем запустить контейнер, запустить новый Шелл в контейнере и перезаписать владельца на все файлы изнутри контейнера на пользователя который запускает узел. После этого можно убрать права на g и o, и оставить только u=rw, и получится как права на config.yaml тут:
Можно, конечно, не заморачиваться и оставить как есть, с o=rwX (как сейчас стоит на storage:)
Нюанс тут:
Эта команда с хоста или внутри контейнера? “user:user” на хосте может не соответствовать ничему в конетейнере. Потому нужно это проверять из оболочки изнутри контейнера.
Подъитоживая:
rsync -a --chmod=o=rwX ...docker run -it <container name or id> /bin/sh- подсмотреть кто владеет config.yaml:
stat config.yaml - назначить рекурсивно того-же владельца на storage:
sudo chown -R meow:woff /mnt/storage/blobs - Убрать доступ группе g и o –
sudo chmod -R 600 /mnt/storage/blobs