UPLOAD FAILED – You are required to sign in to upload your changes to this location in filekit
خطای Word: UPLOAD FAILED – You are required to sign in to upload your changes to this location
این خطا یعنی Word هنگام آپلود تغییرات (معمولاً Save/AutoSave) به مسیر شبکه/وب،
دیگر نمیتواند با همان هویت قبلی احراز هویت کند.
در عمل، Word تلاش میکند عملیاتهایی مثل PUT/LOCK/UNLOCK را روی endpoint انجام دهد، اما به جای پذیرش، پاسخهایی مثل 401 Unauthorized یا 302 Redirect به صفحه login (یا حتی HTML از WAF/Proxy) دریافت میکند.
UPLOAD FAILED
You are required to sign in to upload your changes to this location
این خطا معمولاً مشکل “فایل” نیست؛ مشکل session/credential/auth است. Word برای دانلود ممکن است یکبار موفق شده باشد، اما برای آپلود (Write) که حساستر است، احراز هویت/مجوزها یا متدهای WebDAV شکست میخورند.
علتهای رایج (Root Causes)
اگر backend مبتنی بر session باشد (یا لایهای مثل WAF)، بعد از مدتی درخواستهای PUT/LOCK را به login redirect میکند.
بعضی سیستمها GET را آزادتر میگذارند اما PUT/LOCK نیازمند policy/permission سختگیرانهتر است.
Word ممکن است با یک هویت باز کرده باشد ولی هنگام آپلود نتواند همان credential را refresh کند (WAM/ADAL/Modern Auth، یا credential caching).
mismatch در SPN، fallback اشتباه، multi-hop، یا تغییر hostname (مثلاً redirect) باعث شکست IWA میشود.
Office هنوز در خیلی جاها به تنظیمات WinINET/IE zones تکیه دارد. اگر سایت در zone اشتباه باشد، SSO یا credential prompt درست انجام نمیشود.
Word HTML را نمیتواند بهعنوان پاسخ معتبر PUT پردازش کند؛ نتیجه همان پیام sign-in required است.
کاربر میتواند بخواند ولی حق نوشتن یا قفل کردن ندارد؛ سیستم بهجای خطای شفاف، sign-in میخواهد.
در IIS، Proxy، یا WAF ممکن است PUT یا LOCK ممنوع باشد یا فقط GET/POST اجازه داشته باشند.
چرا Word میگوید «Sign in required» حتی اگر کاربر لاگین است؟
چون Word یک کلاینت HTTP/WebDAV است و “لاگین بودن” برایش یعنی: در لحظه انجام درخواست آپلود، سرور پاسخ قابلقبول بدهد. اگر سرور:
- 401 برگرداند،
- یا 302 به login redirect کند،
- یا صفحه HTML بدهد (WAF/login/error page)،
- یا TLS/cert هشدار ایجاد کند،
Word آن را معادل «باید دوباره sign in کنی» تفسیر میکند.
Runbook عیبیابی (Client-side) — سریع و عملی
- یکبار Close/Exit کامل Word و باز کردن مجددفقط بستن فایل کافی نیست؛ Word را کامل ببندید (از Task Manager مطمئن شوید
WINWORD.EXEباقی نمانده). این کار session/credential cache را از نو میسازد. - Sign out / Sign in داخل Office (اگر Modern Auth دارید)File > Account: خروج و ورود مجدد گاهی توکنهای مشکلدار را درست میکند.
- Credential Manager را بررسی کنیددر Windows Credential Manager، ورودیهای مرتبط با hostname سرویس (WebDAV/SharePoint/Reverse Proxy) را حذف/بازسازی کنید تا credential اشتباه cache نشده باشد.
- تست از مسیر محلی (Golden Test)فایل را local ذخیره کنید و ببینید مشکل فقط روی آپلود رخ میدهد یا فایل هم مشکل دارد. اگر local OK است، تمرکز را بگذارید روی Auth/Server/WebDAV.
- Zone/Trusted Siteshostname سرویس را در Trusted Sites یا Local Intranet (طبق استاندارد سازمان) قرار دهید تا Integrated Auth/SSO قابلاعتمادتر شود.
- VPN/Proxy/Network Path را چک کنیداگر کاربر پشت proxy است یا مسیر CRL/OCSP بسته است، ممکن است Office در HTTPS به مشکل بخورد و sign-in loop ایجاد شود.
Runbook عیبیابی (Server-side) — برای تیم IIS/WebDAV/WAF
1) در لاگها دنبال این الگوها بگردید
- 401 برای متدهای
PUT/LOCK/PROPFIND - 302 به
/loginیا SSO endpoint - 403 مخصوصاً وقتی WAF rule فعال میشود
- 405 Method Not Allowed یا 501 Not Implemented (ممنوع بودن متد)
- 409 Conflict یا خطاهای Locking/Versioning
2) مطمئن شوید endpoint برای WebDAV “واقعاً” WebDAV است
Word برای آپلود تغییرات معمولاً به رفتارهای زیر نیاز دارد:
OPTIONS
PROPFIND
HEAD
PUT
LOCK
UNLOCK3) Redirect / Rewrite را برای متدهای غیر-GET بررسی کنید
بعضی reverse proxyها ruleهایی دارند که فقط برای GET تست شده و برای PUT/LOCK اشتباهاً redirect به login یا به hostname داخلی میدهند. Word معمولاً redirect روی PUT را خوب تحمل نمیکند.
4) Permissions و مکانیزم Lock
- کاربر باید Write permission واقعی داشته باشد.
- اگر سیستم Locking دارد، کاربر باید اجازه LOCK/UNLOCK هم داشته باشد.
- اگر backend قفل قدیمی را orphan کرده، آپلود با conflict شکست میخورد.
5) Content-Length / Chunking / Request body limits
بعضی WAF/Proxyها آپلودهای Office را به خاطر: حداکثر اندازه درخواست، chunked transfer، یا inspection rules قطع میکنند و یک HTML error page میدهند؛ Word آن را sign-in required نشان میدهد.
نشانههای تشخیص سریع
اغلب: Write permission / WebDAV methods / WAF برای PUT/LOCK سختگیر است.
اغلب: session timeout / token expiry / load balancer session persistence.
اغلب: مجوزها، گروهها، SPN/kerberos، یا policyهای متفاوت (zone/proxy).
اغلب: Word WebDAV رفتار متفاوتی از browser دارد (LOCK/PROPFIND)، یا redirect/auth flow با Office ناسازگار است.
راهکارهای عملی (جمعبندی اجرایی)
- تضمین کنید پاسخ سرور برای PUT/LOCK، HTML/redirect نیست؛ باید وضعیتهای WebDAV/HTTP درست برگردد.
- Auth را استاندارد کنید (ترجیحاً Integrated Auth بدون redirectهای عجیب برای endpoint فایل).
- hostname نهایی و certificate دقیق و پایدار باشد (بدون جهش به نام داخلی/دیگر).
- WAF/Proxy rules را برای ترافیک Office/WebDAV تنظیم کنید (متدها و body limits).
- Permissions را برای Write/Lock/Versioning بررسی کنید.
- اگر مشکل intermittent است، session timeout و load balancer persistence را چک کنید.
این خطا با «Specified path wasn’t found» چه فرقی دارد؟
«Specified path wasn’t found» بیشتر به path mapping / 404 / rewrite غلط اشاره دارد. اما «You are required to sign in…» بیشتر نشانه شکست احراز هویت در عملیات آپلود است (401 یا redirect به login)، حتی اگر path درست باشد.
اگر مجبور باشیم فقط یک تست انجام دهیم، بهترین چیست؟
روی همان URL، دقیقاً لحظه Save، ببینید درخواست PUT/LOCK چه پاسخ HTTP میگیرد (401؟ 302؟ 403؟ 405؟ HTML؟). این پاسخ معمولاً root cause را لو میدهد.
جمعبندی
خطای UPLOAD FAILED – You are required to sign in to upload your changes to this location یعنی Word در مسیر آپلود (Write) نتوانسته احراز هویت/مجوز لازم را بگیرد.
شایعترین ریشهها: 401/302 به login، session timeout، block شدن متدهای WebDAV مثل PUT/LOCK، مشکل zone/credential cache،
یا پاسخ HTML از WAF/Reverse Proxy.