Cp не может создать обычный файл
Обновлено: 03.07.2024
Теперь мы попробовали alpha12 на нашей ферме CI. У MinGW сейчас проблема. Кажется, произошла ошибка с каталогом "test".
Использование: i686-7.3.0-release-posix-dwarf-rt_v5-rev0
Вывод ЭК
Конфигурация
"qc", CC => "gcc", CFLAGS => "-Wall -O3 -fomit-frame-pointer", HASHBANGPERL => "/usr/bin/env perl", RANLIB => "ranlib", RC => "windres", asm_arch => "x86", bn_ops => "BN_LLONG", build_file => "Makefile", build_scheme => [ "unified", "unix" ], cflags => "-m32", cppflags => "-DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_MT", определяет => [ "OPENSSL_BUILDING_OPENSSL" ], отключает => [ ], dso_scheme => "win32", включает => [ ], ex_libs => "-lws2_32 -lgdi32 - lcrypt32", включает => [ ], lflags => "", lib_cflags => "", lib_cppflags => "-DL_ENDIAN", lib_defines => [ ], module_cflags => "", module_cxxflags => undef, module_ldflags => " -static-libgcc -shared -Wl, --enable-auto-image-base", multilib => "", perl_platform => "mingw", perlasm_scheme => "coff", shared_argfileflag => "\@", shared_cflag = > "", shared_cppflags => "_WINDLL", shared_defflag => "", shared_defines => [ ], shared_impflag => "-Wl,--out-implib -static-libgcc -shared -Wl,--enable-auto- образ-база", shared_rcflag => "--target=pe-i386 ", shared_target => "mingw-shared", sys_id => "MINGW32", thread_define => [ ], thread_scheme => "winthreads", unistd => " ", uplink_arch => "x86", Записанная среда: AR = BUILDFILE = CC = CFLAGS = CPPFLAGS = CROSS_COMPILE = CXX = CXXFLAGS = HASHBANGPERL = LDFLAGS = LDLIBS = OPENSSL_LOCAL_CONFIG_DIR = PERL = RANLIB = RC = RCFLAGS = WINDRES = __CNF_CFLAGS = __CNF_CPPDEFINES = __CNF_CPPFLAGS = __CNF_CPPINCLUDES = __CNF_CXXFLAGS = __CNF_LDFLAGS = __CNF_LDLIBS = Makevars: AR = AR ARFLAGS = qc CC = gcc CFLAGS = -Wall -O3 -fomit-frame-pointer -Os -fstack-protector-strong CPPDEFINES = CPPFLAGS = CPPINCLUDES = CXXFLAGS = -Os -fstack-protector-strong HASHBANGPERL = /usr/bin/env perl LDFLAGS = LDLIBS = PERL = perl RANLIB = ranlib RC = windres RCFLAGS ar", ARFLAGS => "qc", CC => "gcc", CFLAGS => "-Wall -O3 -fomit-frame-pointer", HASHBANGPERL = > "/usr/bin/env perl", RANLIB => "ranlib", RC => "windres", asm_arch => "x86", bn_ops => "BN_LLONG", build_file => "Makefile", build_scheme => [ "единый ", "unix" ], cflags => "-m32", cppflags => "-DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_MT", defines => [ "OPENSSL_BUILDING_OPENSSL" ], disable => [ ], dso_scheme => "win32" , enable => [ ], ex_libs => "-lws2_32 -lgdi32 -lcrypt32", include => [ ], lflags => "", lib_cflags => "", lib_cppflags => "-DL_ENDIAN", lib_define => [ ] , module_cflags => "", module_cxxflags => undef, module_ldflags => "-static-libgcc -shared -Wl, --enable-auto-image-base", multilib => "", perl_platform => "mingw", perlasm_scheme => "coff", shared_argfileflag => "\@", shared_cflag => "", shared_cppflags => "_WINDLL", shared_defflag => "", shared_defines => [ ], shared_impflag => "-Wl,--out- implib -static-libgcc -shared -Wl, --enable-auto-image-base", shared_rcflag => "--target=pe-i386", shared_target => "mingw-shared", sys_id => "MINGW32", thread_define => [ ], thread_scheme => "winthreads", unistd => " ", uplink_arch => "x86", Записанная среда: AR = BUILDFILE = CC = CFLAGS = CPPFLAGS = CROSS_COMPILE = CXX = CXXFLAGS = HASHBANGPERL = LDFLAGS = LDLIBS = OPENSSL_LOCAL_CONFIG_DIR = PERL = RANLIB = RC = RCFLAGS = WINDRES = __CNF_CFLAGS = __CNF_CPPDEFINES = __CNF_CPPFLAGS = __CNF_CPPINCLUDES = __CNF_CXXFLAGS = __CNF_LDFLAGS = __CNF_LDLIBS = Makevars: AR = ар ARFLAGS = дс CC = GCC CFLAGS = -Wall - O3 -fomit-frame-pointer -Os -fstack-protector-strong CPPDEFINES = CPPFLAGS = CPPINCLUDES = CXXFLAGS = -Os -fstack-protector-strong HASHBANGPERL = /usr/bin/env perl LDFLAGS = LDLIBS = PERL = perl RANLIB = ranlib RC = ветрогенераторы RCFLAGS =
Затем прикрепляю докер, нашел следующие логи:
Есть предложения по этому поводу?
Текст был успешно обновлен, но возникли следующие ошибки:
комментарий zhiweifang от 20 ноября 2018 г.
Я изменил права доступа к DSTClusterConfig и томам, и все заработало.
X-lem прокомментировал 23 февраля 2019 г. •
@mathielo Актуально для этого вопроса. Недавно у моего сервера были проблемы. Мне удалось извлечь папку DSTClusterConfig. Я пересобрал сервер, снова просмотрел документацию. И поместил мою папку DSTClusterConfig в папку dst-dedicated-server.
Запустил сервер и все работает нормально (насколько я могу судить), кроме модов. По какой-то причине я продолжаю получать ошибки, такие как:
Я также получаю эту ошибку при завершении работы, которая не связана с модом.
[00:09:55]: [КРИТИЧЕСКОЕ] Не удалось сохранить файл: /home/dst/.klei//DoNotStarveTogether/DSTWhalesCluster/Master/save/saveindex
Я использовал chown -R пользователя DSTClusterConfig, чтобы изменить пользователя, который использовался для установки всего и когда я запускал docker-compose up . Имеет ли значение, к какой группе принадлежат файлы.Я не уверен, почему он может успешно запускать, играть и сохранять игру, но не использовать моды.
прокомментировал mathielo 26 февраля 2019 г.
Привет, @X-lem! Все проблемы вроде одинаковые, разрешения в папке /DSTClusterConfig. Наиболее распространенной причиной этого является неправильное владение, поскольку уровни разрешений по умолчанию (0755) должны работать, если пользователь или группа правы.
Запустил сервер и все работает нормально (насколько я могу судить), кроме модов.
Нет, скорее всего, у вас тоже не будет сохранений. Вы сможете запустить сервер и играть, но он не сохранит прогресс (поскольку он получает отказ в доступе).
Я использовал chown -R user DSTClusterConfig, чтобы изменить пользователя, которого я использовал для установки всего, и когда я запускаю docker-compose up
☝️ Это странно, потому что эта команда должна решить проблему с правами собственности. Что вы видите, когда заходите в DSTClusterConfig и запускаете приведенные ниже команды?
Можете ли вы подтвердить, что ваш пользователь/группа действительно указан там как владелец DSTClusterConfig и всех его подпапок и файлов? Если да, то как насчет папки выше, корня проекта? Он принадлежит вашему пользователю?
Если проблема еще не решена, какая у вас ОС?
Прокомментировал X-lem 26 февраля 2019 г.
Спасибо, @mathielo, что нашли время! Я ценю это.
Я выполнил команду в соответствии с инструкциями. Вот мой вывод по двум папкам. В настоящее время я использую Ubuntu, 18.04. Корень проекта также принадлежит моему пользователю.
zhiweifang прокомментировал 27 февраля 2019 г.
В моем случае я думаю, что это проблема конфигурации докера.
Я заметил, что контейнер docker не принадлежит моему пользователю, хотя он запускается в моей учетной записи пользователя командой docker-compose up -d .
Использование htop для отображения дополнительных сведений:
где zwfang является моей учетной записью пользователя, но мой док-контейнер dst принадлежит ltguo (не привилегированному пользователю). Я тестирую другие контейнеры и получаю такие же результаты.
Я мало что знаю о Docker, но думаю, что он был неправильно настроен.
прокомментировал mathielo 28 февраля 2019 г.
Черт, это действительно странно. Я никогда раньше не видел, чтобы разные пользователи запускали процессы докера 🤔 😕
Возможно, что-то действительно не так с установкой Docker. @ X-lem, вы можете проверить с помощью htop, если у вас такая же проблема, как у @zhiweifang? Процессы запускают разные пользователи?
Я вижу, вы предоставили 775 разрешений для папок, но если у вас возникла та же проблема, а (другой) пользователь не принадлежит к группе ubuntu, у него все равно не будет разрешений на запись.
Я знаю, что это может быть слишком много, но не могли бы вы описать шаги, предпринятые с самого начала? Это ваш компьютер с Ubuntu или вы приобрели для него виртуальную/размещенную машину? Как был установлен докер?
На самом деле мне очень любопытно понять, как это может произойти. Я запускал этот образ на нескольких разных установках Debian, Ubuntu и MacOS и никогда не сталкивался с такой проблемой 😔 Если я найду способ воспроизвести его, я могу поискать «исправление» для него, будь то изменение чего-либо в образах докеров. /setup или в документации.
прокомментировал mathielo 28 февраля 2019 г.
Кстати, если вы измените разрешения на 777, как это сделал @zhiweifang, сервер должен иметь возможность правильно запускать, сохранять и применять моды. Я знаю, что это не правильное решение, но это способ, чтобы вы могли играть, пока мы разбираемся 🤓
Прокомментировал X-lem 28 февраля 2019 г.
@mathielo Сделал снимок htob . Мне кажется, что пользователь ubuntu запускает сервер DST. Я не понимаю, почему, поскольку я запускаю команду docker-compose up -d с регистрацией суперпользователя. Ubuntu — это пользователь, который, как я полагаю, автоматически создается AWS при запуске экземпляра (я предполагаю, что группа Ubuntu также создается автоматически, поскольку я ее не создавал). Я не уверен, суперпользователь это или нет. Должен ли я тогда назначить regis группе Ubuntu?
Порядок работы
При настройке сервера я в основном следовал документации. Я опубликую ниже, что именно я сделал. Для этого я запускаю экземпляр EC2 AWS. В частности, ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-20180912 (ami-0bbe6b35405ecebdb)
sudo apt-get установить git
Я создал своего суперпользователя.
adduser regis
usermod -aG sudo regis
Затем я переключился на пользователя
Следовал руководству Ubuntu по установке Docker.
sudo apt-получить обновление
Убедился, что у меня есть ключ с отпечатком пальца. Ожидаемые результаты были распечатаны.
отпечаток ключа apt 0EBFCD88
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
создал группу докеров
sudo groupadd docker
sudo usermod -aG docker regis
выйти и снова войти.
Запустил docker run hello-world
Я думаю, в этот момент мне сказали, что мне нужно установить docker compose. Я считаю, что он предложил запустить
sudo установить docker-compose
Повторно запустил docker run hello-world, и он распечатал ожидаемые результаты.
Затем клонировал репозиторий git
Я удалил папку DSTClusterConfig и заменил ее своей собственной.
Запустил sudo chown regis dst-dedicated-server/, чтобы убедиться, что пользователь владеет всем.
Это все, что касается процесса. Очевидно, я также добавил свой токен кластера.
прокомментировал mathielo 14 марта 2019 г.
Привет, @X-lem, спасибо за подробный ответ, извини, что не смог ответить тебе раньше. Я не вижу недостатков в шагах, они выглядят правильно и должны работать нормально. Не уверен, что проблема в том, что что-то было перемещено (это не должно быть так, как вы это сделали) или дело в AWS.
Должен ли я тогда также назначить regis группе Ubuntu?
Полагаю, тогда. Это должно решить проблемы с разрешениями.
Выбирая решение VPS, убедитесь, что оно не работает на основе концепции кредитов процессора. Когда сервер работает, сегменты простаивают при загрузке ЦП примерно на 30%; когда игроки подключаются, они постоянно держат 90~100%. Поэтому выбирайте сервис, который позволяет использовать ресурсы в полной мере, иначе у вас возникнут проблемы.
Не рекомендуется использовать инстансы AWS EC2, основанные на модели «кредиты ЦП». Эта модель работает только для запуска приложений с низкой загрузкой ЦП с возможными всплесками. Выделенный сервер использует много ресурсов ЦП (особенно когда подключен хотя бы один игрок), поэтому вскоре вы превысите свои кредиты, и AWS ограничит вычислительную мощность вашего экземпляра.
X-lem прокомментировал 16 марта 2019 г. •
@mathielo Не беспокойтесь 😄 Я ценю помощь. Я также назначу своего пользователя в группу Ubuntu. Если это не сработает ни 🤷♂️ chmod 777, то я полагаю.
Я не думаю, что использую кредитную модель в AWS. Я плачу пару баксов в месяц за это в зависимости от использования. Модель, которую я использую, не является бесплатным уровнем, поэтому я не думаю, что они ограничивают ее (за исключением случаев, когда она достигает предела t3.small, с которым у меня пока не было проблем).
Редактировать: на самом деле не похоже, что существует группа Ubuntu. странно.
прокомментировал thatjames 31 июля 2019 г. •
@X-lem, это потому, что вы создали пользователя.
id regis должен возвращать что-то вроде uid=1001(regis) gid=1001(regis)
В Docker пользовательский dst сопоставляется с 1000. Вот почему вы получаете ошибки отказа в доступе: вам нужно переназначить биты UID и GID для envvars
В файле создания необходимо следующее:
Проделайте это как для dst_master, так и для dst_caves
@mathielo отправляет запрос на внесение изменений в файл компоновки
ДавХау прокомментировал 28 апреля 2020 г. •
Привет, @zhiweifang, обычно это связано с правами доступа к файлам, которые вы клонировали из git. Возможно ли, что вы либо запустили sudo git clone (.), либо клонировали его с другим пользователем? Запустите ls -l и посмотрите, совпадает ли право собственности на файлы с пользователем, выполняющим команду docker-compose up.
Это происходит потому, что Docker использует тома для сохранения некоторых файлов, таких как загруженные моды и сгенерированный мир. и его спасает. Если у пользователя, выполняющего команду Docker, нет разрешения на запись в папки проекта, вы получите эту ошибку разрешения.
Это неправильно. Какой пользователь используется для выполнения каких-либо команд docker/docker-compose, совершенно не имеет значения. Docker использует процесс корневого демона, который в конечном итоге делает все за вас. Пользователь, взаимодействующий с демоном docker, ни на что не влияет.
Пользователь, который используется внутри контейнера, определяется внутри Dockerfile или процесса, работающего внутри контейнера. С вашим изображением докера этот пользователь имеет UID = 1000 и GID = 1000.
Это означает, что единственная возможная конфигурация, с которой этот проект создания докеров будет работать, — это если люди извлекают проект git на своей хост-системе с пользователем/группой, точно совпадающим с идентификатором 1000. Все остальное не удастся.
Читайте также: