ข้อผิดพลาด rsync: ล้มเหลวในการตั้งเวลาใน“ / foo / bar”: ไม่อนุญาตให้ใช้งาน

194

ฉันได้รับข้อผิดพลาดที่สับสนจาก rsync และสิ่งแรกเริ่มที่ฉันค้นหาจากการค้นหาทางเว็บ (รวมถึง chmod'ing ปกติทั้งหมด) ไม่ได้แก้ไข:

rsync: failed to set times on "/foo/bar": Operation not permitted (1)
rsync error: some files could not be transferred (code 23) 
  at /SourceCache/rsync/rsync-35.2/rsync/main.c(992) [sender=2.6.9]

ดูเหมือนว่าจะทำงานได้แม้จะมีข้อผิดพลาด แต่ก็ดีที่จะกำจัดออก

rsync file-transfer

— dreeves
แหล่งที่มา

ไม่เพียงไดเรกทอรีปกติเท่าที่ฉันสามารถบอกได้

— dreeves

เพิ่งพบปัญหาที่คล้ายกันถึงแม้ว่ารหัสข้อผิดพลาดของฉันคือ 22: rsync: ล้มเหลวในการตั้งเวลาใน ... อาร์กิวเมนต์ไม่ถูกต้อง (22) หลังจากการตรวจสอบบางอย่างปรากฎว่าไฟล์ของฉันถูกแก้ไขล่าสุดเมื่อปี 1956! วิธีแก้ไข: แตะไฟล์ทั้งหมดแก้ไขปัญหา :) "ค้นหา. -print0 | xargs -0 touch"

— KIAaze

ฉันพบว่าหากคุณตั้งค่างาน cron ไปยังปลายทางเดียวกันข้อผิดพลาดนี้จะปรากฏขึ้น การเปลี่ยนเวลาสำหรับงาน cron (crontab) จะช่วยให้รอบ ในกรณีของฉันฉันได้รับข้อผิดพลาดนี้ถ้าฉันทำ rysnc ด้วยตนเองถ้าฉันได้ตั้งค่างาน cron ด้วย

— NelsonGon

286

หาก/foo/barอยู่ใน NFS (หรืออาจเป็นระบบไฟล์ FUSE บางส่วน) นั่นอาจเป็นปัญหา

ไม่ว่าจะด้วยวิธีใดการเพิ่ม-O/ --omit-dir-timesลงในบรรทัดคำสั่งของคุณจะเป็นการหลีกเลี่ยงการพยายามตั้งเวลาแก้ไขในไดเรกทอรี

— จอนไบรต์
แหล่งที่มา

8

สิ่งที่ตลกคือฉันกำลังซิงค์ ext3 กับ ext3 ทั้งสอง OS เป็น linux ฉันไม่เคยใช้สวิตช์นี้มาก่อน -O ทำกลอุบาย แต่ฉันหวังว่าฉันไม่จำเป็นต้องใช้มัน

— d -_- b

3

ขอบคุณ! ปรากฎโฮสต์ VPS บางตัว (เช่น xlshosting.nl) ใช้สิ่งนี้ภายในซึ่งอาจทำให้เกิดปัญหากับ rsync

— เฟรดเดอริก

2

ฉันมีปัญหาเดียวกัน rsyncing จาก Linux ext4 ถึง Linux ext4: "ไม่สามารถตั้งเวลา: การดำเนินการไม่ได้รับอนุญาต" สำหรับsymlinkไม่ใช่ไดเรกทอรี -Oไม่ช่วยชัด สิ่งนี้ไม่เคยเกิดขึ้นเมื่อพาร์ติชันสำรองของฉันเป็น ext3 แทนที่จะเป็น ext4

— Marius Gedminas

10

ฉันใช้ rsync -avc และการเพิ่ม -O ก็ไม่ได้ช่วยอะไร จากนั้นฉันอ่านว่า -a คือ equiv to -rlptgoD ซึ่งรวมถึง -t ซึ่งฉันเดาว่าจะแทนที่ -O ดังนั้นสำหรับฉันการแก้ไขคือการใช้ -rlpgoDvc

— dlink

3

@dlink คุณสามารถเพิ่ม--no-tเพื่อลบตัวเลือกโดยนัย

— Noam Nelke

86

ปัญหาอาจเกิดจาก / foo / bar ที่ไม่ได้เป็นเจ้าของโดยกระบวนการเขียนบนระบบ darwin ระยะไกล (OS X) ทางออกสำหรับปัญหานี้คือการตั้งเจ้าของให้เพียงพอบนไซต์ระยะไกล

เนื่องจากคำตอบนี้ได้รับการโหวตและหวังว่าจะเป็นประโยชน์กับใครบางคนฉันจึงขยายคำตอบเพื่อให้ชัดเจนยิ่งขึ้น

เหตุผลที่สิ่งนี้เกิดขึ้นคือ rsync อาจพยายามตั้งค่าเวลาการดัดแปลงโดยพลการ (mtime) เมื่อทำการคัดลอกไฟล์

เพื่อที่จะทำระบบของดาร์วินนี้utime()ฟังก์ชั่นที่ต้องใช้ขั้นตอนการเขียน uid ที่มีประสิทธิภาพเป็นอย่างใดอย่างหนึ่งเช่นเดียวกับ uid ไฟล์หรือหนึ่งในผู้ใช้ super ให้ดูopengroup หน้า ตรวจสอบการสนทนานี้ในรายชื่อผู้รับจดหมาย rsync เป็นข้อมูลอ้างอิง

— anddam
แหล่งที่มา

10

เหมือนกันบน Linux (Debian Squeeze ในกรณีของฉัน) ... หากฉันไม่ใช่เจ้าของไดเรกทอรีเป้าหมาย rsync จะแสดงข้อความข้อผิดพลาด "ไม่สามารถตั้งค่าเวลาได้" (มีสิทธิ์ในการเขียนในไดเรกทอรีไม่เพียงพอ)

— ddekany

1

ฉันติดอยู่ในปัญหาเดียวกัน จนกระทั่งเมานต์ NTFS ด้วย uid = ผู้ใช้

— gavenkoa

3

ข้อผิดพลาดนี้หายไปสำหรับฉันเมื่อฉันเปลี่ยนเจ้าของไดเรกทอรีที่ฉันพยายามที่จะส่งผลกระทบ (บนเซิร์ฟเวอร์ระยะไกล) โดยใช้คำสั่ง rsync ให้กับผู้ใช้คนเดียวกับผู้ที่พยายามเข้าสู่ระบบผ่านทาง rsync ในสคริปต์ Bash ท้องถิ่นของฉัน ในคำอื่น ๆ : ผมพยายามที่จะเขียนไป/remote/path/to/foo/barบนเซิร์ฟเวอร์ระยะไกลด้วยคำสั่งนี้rsync -avzP --exclude '.DS_Store' /local/path/to/foo/bar/ user1@1.2.3.4:/remote/path/to/foo/bar และได้รับข้อความข้อผิดพลาดเดียวกันซึ่งเดินออกไปเมื่อฉันทำuser1เจ้าของ/remoe/path/to/foo/barเช่นนี้$ chown -R user1 /remote/path/to/foo/bar

— racl101

1

หากคุณแชร์ไฟล์ของคุณกับผู้ใช้คนอื่นในกลุ่มเช่นคุณใช้หมุดเล็ก ๆ การเปลี่ยนเจ้าของไม่ใช่วิธีแก้ปัญหาจริงๆ เราไม่ใช้ -t และเพิ่ม -O เพื่อป้องกันคำเตือนนี้

— R. van Twisk

1

คุณสามารถขยายคำตอบให้ละเอียดได้หรือไม่หากผู้ใช้เป็นส่วนหนึ่งของกลุ่มที่เป็นเจ้าของไฟล์ / dir หากควรหรือไม่ควรทำงาน

— เอลียาห์ลินน์

4

ในฐานะที่เป็น @ racl101 มีความเห็นเกี่ยวกับคำตอบปัญหานี้อาจจะเกี่ยวข้องกับการใช้โฟลเดอร์ คำสั่ง rsync ควรทำโดยผู้ใช้รายเดียวกับเจ้าของโฟลเดอร์ หากไม่เหมือนกันคุณสามารถเปลี่ยนได้

chown -R userCorrect /remote/path/to/foo/bar

— Lud Akell
แหล่งที่มา

2

ปัญหาในกรณีของฉันคือ "เมานต์รับ" ถูกเมานต์ไม่ถูกต้อง มันอยู่ในโหมดอ่านอย่างเดียว (สำหรับเหตุผลเพิ่มเติมบางอย่าง) ดูเหมือนว่า rsync กำลังคัดลอกไฟล์ แต่ไม่ใช่ ฉันตรวจสอบไฟล์ fstab ของฉันและเปลี่ยนตัวเลือกการเมาท์เป็นค่าเริ่มต้นติดตั้งระบบไฟล์อีกครั้งและดำเนินการ rsync อีกครั้ง ทุกอย่างดีแล้ว

— ripah
แหล่งที่มา

2

ผมมีปัญหาเหมือนกัน. สำหรับฉันทางออกคือการลบไฟล์ระยะไกลและให้rsyncสร้างอีกครั้ง

— shintaroid
แหล่งที่มา

0

ฉันเห็นปัญหานั้นเมื่อฉันเขียนไปยังระบบไฟล์ซึ่งไม่สามารถจัดการได้อย่างถูกต้องฉันคิดว่า SMB แชร์หรือ FAT หรือบางอย่าง

ระบบไฟล์เป้าหมายของคุณคืออะไร?

— เดวิดโวเลเวอร์
แหล่งที่มา

ฉันใช้ mac กำลังเชื่อมต่อกับ linux (เครื่องสไลซ์โฮสต์)

— dreeves

อ๊ะแปลก ... เนื่องจากคุณกำลังใช้ rsync บนเครื่อง mac ฉันควรเตือนคุณว่า: มันไม่ได้รักษาคุณสมบัติของไฟล์ OS X ไว้อย่างเหมาะสมดังนั้นสิ่งที่ไม่ดีอาจเกิดขึ้นได้ ดูตัวอย่างเช่น: blog.plasticsfuture.org/2006/04/23/mac-backup-software-harmful

— David Wolever

อย่างไรก็ตามคุณสามารถใช้เวอร์ชันล่าสุดจาก MacPorts ( sudo port install rsync) และมันจะแตกหักน้อยลง วิธีตรวจสอบrsync --version:: rsync เวอร์ชัน 3.0.5 โปรโตคอลรุ่น 30 ... ผนวก, ACLs, xattrs, iconv, Symtimes, แฟล็กไฟล์ ... (ACLs และ xattrs เป็นสิ่งสำคัญ)

— David Wolever

1

rsync บน Macintosh นั้นได้ทำการตั้งค่าคุณสมบัติของไฟล์ทั้งหมดและได้ทำมาเป็นระยะเวลาหนึ่งแล้วโปรดทราบว่าการอ้างอิง URL ที่ว่า

— tgunr

2

คำตอบไม่ควรรวมคำถาม นี่จะเหมาะสมกว่าเป็นความคิดเห็น

— Brian

0

อาจเป็นไปได้ว่าคุณไม่มีสิทธิ์สำหรับไฟล์บางไฟล์ จากบัญชีผู้ดูแลระบบลอง "sudo rsync -av" อีกทางหนึ่งเปิดใช้งานบัญชีรูทและลงชื่อเข้าใช้ในฐานะรูท ที่จะช่วยให้คุณใช้ระบบของคุณอย่างเต็มที่ ;-) ฉันไม่แน่ใจว่าข้างต้น - แอตทริบิวต์เพิ่มจะช่วย แต่ฉันก็โยนมันเกินไปสำหรับการวัดที่ดี

— กัปตัน
แหล่งที่มา

0

เรื่องนี้เกิดขึ้นกับฉันในพาร์ติชันประเภทxfs (rw,relatime,seclabel,attr2,inode64,noquota)ที่ไดเรกทอรีที่เป็นเจ้าของโดยผู้ใช้รายอื่นในกลุ่มเราทั้งสองเป็นสมาชิก ความเป็นสมาชิกกลุ่มได้รับการจัดตั้งขึ้นก่อนที่จะเข้าสู่ระบบและโครงสร้างไดเรกทอรีทั้งหมดเป็นกลุ่มที่เขียนได้ ฉันทำงานด้วยตนเองsudo chown -R otheruser.group directoryและsudo chmod -R g+rw directoryเพื่อยืนยันสิ่งนี้

ฉันยังไม่รู้เลยว่าทำไมตอนแรกมันไม่ทำงาน แต่การเป็นเจ้าของด้วยการsudo chown -R myuser.group directoryแก้ไขมัน อาจเกี่ยวข้องกับ SELinux หรือไม่

— แซมไบรท์แมน
แหล่งที่มา

หน้าคนพูดถึง UID ของแอพ ต้องจับคู่ UID ของไฟล์เพื่อutime()ให้ทำงานได้ คุณยังสามารถเรียกใช้เป็นรูทและทำมันได้ แต่ถ้า UID ของไฟล์ต่างกันพวกเขาจะไม่ยอมให้คุณเปลี่ยนเวลาเป็นอย่างอื่นนอกจาก "ตอนนี้"

— Alexis Wilke

คุณสามารถลิงค์ไปยังหน้าเพจดังกล่าวได้หรือไม่? utime()ไม่มีการเอ่ยถึงเหมือง

— Sam Brightman

1

linux.die.net/man/2/utimeย่อหน้าที่เกี่ยวข้อง: "การเปลี่ยนการประทับเวลาได้รับอนุญาตเมื่อ: กระบวนการมีสิทธิ์ที่เหมาะสมหรือ ID ผู้ใช้ที่มีประสิทธิภาพเท่ากับ ID ผู้ใช้ของไฟล์หรือเวลาเป็น NULL และกระบวนการมี เขียนสิทธิ์สำหรับไฟล์ "

— Alexis Wilke

0

ข้อผิดพลาดนี้อาจปรากฏขึ้นหากคุณเรียกใช้กระบวนการ rsync สำหรับไฟล์ที่ไม่ได้แก้ไขล่าสุดในแหล่งที่มาหรือปลายทาง ... เนื่องจากไม่สามารถกำหนดเวลาสำหรับไฟล์ที่แก้ไขล่าสุด

— Gurdeep Singh
แหล่งที่มา