{"id":36736,"date":"2019-10-31T22:13:26","date_gmt":"2019-10-31T19:13:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/istoriya-problemy-perenosa-docker-storage-docker-root\/"},"modified":"2019-10-31T22:13:26","modified_gmt":"2019-10-31T19:13:26","slug":"istoriya-problemy-perenosa-docker-storage-docker-root","status":"publish","type":"post","link":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/istoriya-problemy-perenosa-docker-storage-docker-root","title":{"rendered":"Historie probl\u00e9mu s p\u0159esunem docker storage (docker root)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u0159ed p\u00e1r dny bylo rozhodnuto p\u0159esunout docker storage (adres\u00e1\u0159, kde Docker ukl\u00e1d\u00e1 v\u0161echny soubory kontejner\u016f a obraz\u016f) na samostatnou partition, kter\u00e1
\nm\u011bla v\u011bt\u0161\u00ed kapacitu. \u00dakol se zd\u00e1l b\u00fdt trivi\u00e1ln\u00ed a nijak neohro\u017eoval...
\n<\/a><\/noindex>
\nZa\u010d\u00edn\u00e1me:<\/p>\n

1. Zastav\u00edme a zabijeme v\u0161echny kontejnery na\u0161\u00ed aplikace: <\/p>\n

docker-compose down<\/code><\/pre>\n
\npokud je kontejnerech mnoho a jsou v r\u016fzn\u00fdch compose, m\u016f\u017eeme to ud\u011blat takto: <\/p>\n
docker rm -f $(docker ps -q)<\/code><\/pre>\n
\n2. Zastav\u00edme docker d\u00e9mon: <\/p>\n
systemctl stop docker<\/code><\/pre>\n
\n3. P\u0159esuneme adres\u00e1\u0159 na po\u017eadovan\u00e9 m\u00edsto: <\/p>\n
cp -r \/var\/lib\/docker \/docker\/data\/storage<\/code><\/pre>\n
\n4. \u0158ekneme docker d\u00e9monu, aby se d\u00edval do nov\u00e9ho adres\u00e1\u0159e. Existuje n\u011bkolik variant: bu\u010f p\u0159es p\u0159\u00edznak -g zadat d\u00e9monu novou cestu, nebo konfigura\u010dn\u00ed soubory systemd, kter\u00e9 jsme pou\u017eili. Nebo symlink. Rozepisovat to nebudu, na internetu je spousta<\/a><\/noindex> n\u00e1vod\u016f na p\u0159esun docker root na nov\u00e9 m\u00edsto.<\/p>\n
5. Spust\u00edme docker d\u00e9mona a sledujeme, aby se d\u00edval, kam m\u00e1: <\/p>\n
systemctl status docker<\/code><\/pre>\n
\nV jednom z \u0159\u00e1dk\u016f v\u00fdstupu bychom m\u011bli vid\u011bt:<\/p>\n
\u251c\u250019493 \/usr\/bin\/dockerd --data-root=\/docker\/data\/storage<\/code><\/pre>\n
\nUjistili jsme se, \u017ee jsme d\u00e9monovi p\u0159edali mo\u017enost, nyn\u00ed zkontrolujeme, zda ji aplikoval (d\u011bkujeme inkvizitor68sl<\/a><\/noindex>)!<\/p>\n
docker info | awk '\/Root Dir\/ {print $NF}' <\/code><\/pre>\n
\n6. Spust\u00edme na\u0161i aplikaci: <\/p>\n
docker-compose up -d<\/code><\/pre>\n
\n7. Kontrolujeme<\/p>\n
A tady za\u010d\u00edn\u00e1 to nejzaj\u00edmav\u011bj\u0161\u00ed, DB, MQ, v\u0161echno je v po\u0159\u00e1dku! Datab\u00e1ze je cel\u00e1, v\u0161echno funguje\u2026 krom\u011b nginx. M\u00e1me svou sestavu nginx s Kerberosem a kurti\u017eankami. A prohl\u00ed\u017een\u00ed log\u016f kontejneru uk\u00e1zalo, \u017ee nem\u016f\u017ee zapisovat do \/var\/tmp \u2014 Permission denied. Protahuji prsty p\u0159es sp\u00e1nky a sna\u017e\u00edm se analyzovat situaci\u2026 Jak to? Docker image se p\u0159ece nem\u011bnil. My jsme jen p\u0159esunuli adres\u00e1\u0159. V\u017edy to fungovalo, a te\u010f najednou\u2026 Pro experiment jsem vstoupil do kontejneru a zm\u011bnil pr\u00e1va na tento adres\u00e1\u0159, byla root, root 755<\/u>, dal root, root 777<\/u>. A v\u0161echno se rozjelo\u2026 V hlav\u011b mi zazn\u011bla my\u0161lenka \u2014 n\u011bjak\u00fd nesmysl\u2026 Myslel jsem si, \u017ee mo\u017en\u00e1 n\u011bco podce\u0148uji\u2026 <\/p>\n
Rozhodl jsem se, \u017ee jsme ztratil pr\u00e1va p\u0159\u00edstupu k soubor\u016fm p\u0159i p\u0159esunu. Zastavili jsme aplikaci, docker d\u00e9mona, smazali novou adres\u00e1\u0159 a provedli kop\u00edrov\u00e1n\u00ed adres\u00e1\u0159e \/var\/lib\/docker ji\u017e s pou\u017eit\u00edm rsync -a<\/code>. <\/p>\n
Mysl\u00edm, \u017ee te\u010f je v\u0161echno v po\u0159\u00e1dku, zved\u00e1me docker, aplikaci.<\/p>\n
Aaa\u2026 the problem remains\u2026 My eye is twitching. I rushed to the console of my virtual machine where I run various tests; I had this nginx image, and I went inside the container, and here in the directory \/var\/tmp the permissions are set to root, root 777. That is, the same ones I had to set manually. But the images are identical! <\/p>\n
XFS file system was used everywhere.<\/u><\/p>\n
I compared it using the command <\/p>\n
docker inspect my-nginx:12345<\/code><\/pre>\n
\nAll hashes are identical, all exactly the same. On the server and on my virtual machine. I deleted the local nginx image and pulled it again from the registry, which for various reasons is on the same machine. And the problem is the same\u2026 Now my second eye is twitching.<\/p>\n
I don\u2019t even remember what thoughts were in my head besides screams of 'AAAAAA' and the like. It\u2019s 4 a.m. outside, and I dug into the Docker source code to understand the principle of hashing image layers. I opened my third energy drink. And in the end, it dawned on me that hashing only takes into account the file, its content, but NOT ACCESS PERMISSIONS!<\/b>So somehow mysteriously our permissions got messed up, and selinux is disabled, acl is not used, and there\u2019s no sticky bit. <\/p>\n
I deleted the local image, also removed the image from the docker registry and pushed it again. And everything worked. It turns out that during the transfer, the permissions got messed up, both inside the local image and inside the image stored in the registry. As I mentioned, for various reasons it was located on the same machine. And thus in the same directory \/var\/lib\/docker.<\/p>\n
And anticipating the question, haven\u2019t we tried pointing Docker back at the old directory \u2014 no, we haven\u2019t tried, unfortunately, circumstances did not allow it. Moreover, I really wanted to figure it out.<\/p>\n
After writing this article, the solution to the problem seems obvious to me, but at the time of the investigation, it did not seem so. Honestly, I googled and did not find similar situations.<\/p>\n
In conclusion: I solved the problem, but I still do not understand the reason =(<\/p>\n
If anyone knows, suspects, or has an idea of possible reasons for this problem \u2014 I would be extremely grateful if you share in the comments!
\n
Zdroj: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041d\u0435 \u0434\u0430\u043b\u0435\u0435, \u0447\u0435\u043c \u043f\u0430\u0440\u0443 \u0434\u043d\u0435\u0439 \u043d\u0430\u0437\u0430\u0434 \u0431\u044b\u043b\u043e \u0440\u0435\u0448\u0435\u043d\u043e \u043d\u0430 \u043e\u0434\u043d\u043e\u043c \u0438\u0437 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0432\u044b\u043d\u0435\u0441\u0442\u0438 docker storage (\u043a\u0430\u0442\u0430\u043b\u043e\u0433, \u0433\u0434\u0435 \u0434\u043e\u043a\u0435\u0440 \u0445\u0440\u0430\u043d\u0438\u0442 \u0432\u0441\u0435 \u0444\u0430\u0439\u043b\u044b \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432, \u043e\u0431\u0440\u0430\u0437\u043e\u0432) \u043d\u0430 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0439 \u0440\u0430\u0437\u0434\u0435\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043e\u0431\u043b\u0430\u0434\u0430\u043b \u0431\u043e\u043b\u044c\u0448\u0435\u0439 \u0435\u043c\u043a\u043e\u0441\u0442\u044c\u044e. \u0417\u0430\u0434\u0430\u0447\u0430, \u043a\u0430\u0437\u0430\u043b\u043e\u0441\u044c \u0431\u044b, \u0442\u0440\u0438\u0432\u0438\u0430\u043b\u044c\u043d\u0430\u044f \u0438 \u043d\u0435 \u043f\u0440\u0435\u0434\u0432\u0435\u0449\u0430\u043b\u0430 \u0431\u0435\u0434\u044b\u2026 \u041f\u0440\u0438\u0441\u0442\u0443\u043f\u0430\u0435\u043c: 1. \u041e\u0441\u0442\u0430\u043d\u0430\u0432\u043b\u0438\u0432\u0430\u0435\u043c \u0438 \u0443\u0431\u0438\u0432\u0430\u0435\u043c \u0432\u0441\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b \u043d\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f: docker-compose down \u0435\u0441\u043b\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043c\u043d\u043e\u0433\u043e, \u0438 \u043e\u043d\u0438 \u0432 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36736","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47The story of the problem of transferring Docker storage (docker root) | ProHoster","description":"Just a couple of days ago, it was decided to move the Docker storage (the directory where Docker stores all container and image files) to a separate partition with greater capacity.","canonical_url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/istoriya-problemy-perenosa-docker-storage-docker-root","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"cs_CZ","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0441\u0442\u043e\u0440\u0438\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u043f\u0435\u0440\u0435\u043d\u043e\u0441\u0430 docker storage (docker root) | ProHoster","og:description":"\u041d\u0435 \u0434\u0430\u043b\u0435\u0435, \u0447\u0435\u043c \u043f\u0430\u0440\u0443 \u0434\u043d\u0435\u0439 \u043d\u0430\u0437\u0430\u0434 \u0431\u044b\u043b\u043e \u0440\u0435\u0448\u0435\u043d\u043e \u043d\u0430 \u043e\u0434\u043d\u043e\u043c \u0438\u0437 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0432\u044b\u043d\u0435\u0441\u0442\u0438 docker storage (\u043a\u0430\u0442\u0430\u043b\u043e\u0433, \u0433\u0434\u0435 \u0434\u043e\u043a\u0435\u0440 \u0445\u0440\u0430\u043d\u0438\u0442 \u0432\u0441\u0435 \u0444\u0430\u0439\u043b\u044b \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432, \u043e\u0431\u0440\u0430\u0437\u043e\u0432) \u043d\u0430 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0439 \u0440\u0430\u0437\u0434\u0435\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043e\u0431\u043b\u0430\u0434\u0430\u043b \u0431\u043e\u043b\u044c\u0448\u0435\u0439 \u0435\u043c\u043a\u043e\u0441\u0442\u044c\u044e.","og:url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/istoriya-problemy-perenosa-docker-storage-docker-root","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:13:26+00:00","article:modified_time":"2019-10-31T19:13:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36736","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 04:38:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:39:24","updated":"2026-01-22 04:38:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/36736","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/comments?post=36736"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/36736\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media?parent=36736"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/categories?post=36736"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/tags?post=36736"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}