رفع خطای UPLOAD FAILED: This file wasn’t uploaded because the specified path wasn’t found on the server در filekit
رفع خطای UPLOAD FAILED: This file wasn’t uploaded because the specified path wasn’t found on the server
این پیام یعنی Word یا یکی از برنامههای Office هنگام ذخیره/آپلود فایل به مقصد سروری، مسیری را که فکر میکند باید فایل در آن قرار بگیرد روی سرور پیدا نکرده است. این مشکل معمولاً به Path Mapping، WebDAV، IIS، Redirect، تغییر نام/حذف پوشه مقصد، یا URL نادرست مربوط میشود.
UPLOAD FAILED
This file wasn’t uploaded because the specified path wasn’t found on the server
Office فایل را برای ذخیره یا آپلود آماده کرده، اما در لحظه ارسال متوجه شده مسیر مقصدی که در آدرس یا session فعلی ثبت شده دیگر معتبر نیست. یعنی ممکن است پوشه روی سرور حذف شده باشد، URL عوض شده باشد، mapping اشتباه باشد، یا redirect باعث شده برنامه به مسیری غیرواقعی برسد.
رایجترین علتهای این خطا
اگر فایل قبلاً از یک مسیر مشخص باز شده باشد ولی آن پوشه rename/delete/move شده باشد، Word هنگام Save دیگر مقصد را پیدا نمیکند.
در WebDAV یا IIS ممکن است URL ظاهراً درست باشد اما به مسیر فیزیکی نامعتبر یا virtual directory اشتباه اشاره کند.
اگر reverse proxy یا IIS rewrite مسیر را تغییر دهد، Office ممکن است مقصد نهایی را path معتبر تشخیص ندهد.
بعضی لینکها بعد از مدتی expire میشوند. Word فایل را باز میکند اما هنگام upload دیگر مسیر معتبر نیست.
کاراکترهای خاص، encoding ناسازگار، فاصلههای غیرعادی یا طول زیاد مسیر میتواند باعث عدم resolve صحیح روی سرور شود.
Virtual directory، authoring rules، request filtering یا physical path ممکن است ناقص تنظیم شده باشند.
بعضی سیستمها در نبود مجوز یا در auth failure پیام path not found میدهند، نه access denied.
اگر URL normalization یا security filtering فعال باشد، مسیر Office روی سرور resolve نمیشود.
در سناریوی WebDAV و IIS دقیقاً چه اتفاقی میافتد؟
کاربر فایل را از یک آدرس HTTP/WebDAV باز میکند. Word آدرس ذخیره را از همان session یا URL میسازد. اگر آن آدرس بعداً به خاطر redirect، احراز هویت، حذف پوشه، تغییر virtual directory یا rewrite ناپایدار شود، هنگام آپلود پیام specified path wasn’t found on the server ظاهر میشود.
- Physical path در IIS ممکن است تغییر کرده باشد ولی URL قدیمی هنوز در گردش باشد.
- Virtual directory یا alias ممکن است حذف یا rename شده باشد.
- Rewrite rule ممکن است فقط برای GET درست باشد، اما PUT/LOCK/PROPFIND را به مسیر غلط ببرد.
- Office ممکن است با URL اولیه فایل را باز کرده باشد اما save را روی URL canonical دیگری انجام دهد که وجود ندارد.
راهکارهای فوری برای کاربر
- فایل را با نام جدید در مسیر محلی Save As کنیداگر ذخیره محلی موفق است، مشکل از خود سند نیست؛ از مسیر مقصد سرور یا upload pipeline است.
- فایل را دوباره از مسیر صحیح باز کنیدممکن است کاربر فایل را از لینکی قدیمی، bookmark منقضی، یا URL موقت باز کرده باشد. فایل را از مسیر اصلی/جدید دوباره باز کنید.
- نام فایل و مسیر را سادهتر کنیدنام خیلی طولانی، کاراکترهای خاص، علائم رزرو شده، یا فاصلههای غیرعادی را حذف کنید.
- اگر پوشه مقصد تغییر کرده، در پوشه موجود جدید ذخیره کنیداگر تیم IT مسیر یا ساختار پوشهها را عوض کرده، باید فایل در location جدید ذخیره شود.
- نشست احراز هویت را تازهسازی کنیداز برنامه خارج شوید، دوباره sign-in کنید یا session وب/WebDAV را renew کنید.
عیبیابی تخصصی برای تیم IT / ادمین
1) وجود واقعی مسیر مقصد را بررسی کنید
- آیا physical folder واقعاً روی سرور وجود دارد؟
- آیا virtual directory / alias هنوز همان نام قبلی را دارد؟
- آیا مسیر بعد از migration یا rename تغییر کرده است؟
2) mapping بین URL و physical path را در IIS کنترل کنید
- Site bindings، virtual directories، application roots و physical pathها را چک کنید.
- اگر UNC path استفاده میشود، credential و availability share را بررسی کنید.
3) Rewrite / Redirect را برای متدهای Office بررسی کنید
خیلی از تنظیمات فقط GET را درست پوشش میدهند، اما Office برای ذخیره ممکن است از OPTIONS، PROPFIND، PUT، LOCK و UNLOCK استفاده کند.
اگر این متدها به مسیر اشتباه rewrite شوند، کاربر پیام path not found میگیرد.
4) WAF / Reverse Proxy / Gateway را بررسی کنید
- آیا URL normalization کاراکترها یا slashها را تغییر میدهد؟
- آیا encoded pathها decode و سپس خراب میشوند؟
- آیا متدهای WebDAV block شدهاند یا به upstream اشتباه میروند؟
5) لاگها را همزمان بررسی کنید
- در IIS log ببینید درخواست save/upload به کدام URL خورده است.
- کدهای
404،405،401،403یا302را دنبال کنید. - اگر در upstream یا application log مسیر دیگری ثبت شده، mismatch وجود دارد.
6) دسترسی مؤثر و احراز هویت را تست کنید
- کاربر ممکن است فایل را بخواند ولی write path برایش resolve نشود.
- در UNC/Share/IIS باید مجوز effective account بررسی شود، نه فقط user ظاهری.
الگوهای شایع ریشه مشکل
فایلها هنوز از URL قدیمی باز میشوند ولی مقصد ذخیره دیگر وجود ندارد.
مسیرهای encoded یا متدهای WebDAV دیگر مثل قبل به سرور backend نمیرسند.
مشکل معمولاً از encoding، طول مسیر، کاراکتر خاص یا rewrite pattern است.
GET درست است ولی pipeline ذخیره (PUT/LOCK/UNLOCK/PROPFIND) روی path معتبر resolve نمیشود.
چکلیست سریع تشخیص
- آیا پوشه مقصد هنوز واقعاً روی سرور وجود دارد؟
- آیا URL فایل قدیمی/موقت/redirected است؟
- آیا فایل در مسیر محلی بدون مشکل ذخیره میشود؟
- آیا روی متدهای WebDAV، 404 یا 405 در لاگ دیده میشود؟
- آیا اخیراً alias، vdir، rewrite rule یا physical path تغییر کرده است؟
آیا این خطا همیشه یعنی پوشه واقعاً وجود ندارد؟
نه. گاهی مسیر وجود دارد اما به دلیل auth failure، rewrite غلط، یا block شدن متدها، Office نمیتواند آن را resolve کند و همان پیام path not found را نشان میدهد.
چرا فایل باز میشود ولی آپلود/ذخیره انجام نمیشود؟
چون مسیر خواندن و مسیر نوشتن همیشه یکسان رفتار نمیکنند. ممکن است GET کار کند اما متدهای ذخیره مثل PUT یا LOCK به مسیر دیگری بروند یا block شوند.
بهترین تست سریع برای کاربر چیست؟
Save As به مسیر محلی. اگر محلی جواب داد، مشکل تقریباً قطعاً در path سرور، WebDAV، redirect یا authentication/session است.