tas mount issue

[jhnnr]

I have successfully mounted tas into /mnt/tg-drive

$ tas mount /mnt/tg-drive

🗂️  Mounting Telegram as filesystem...

✔ Enter your encryption password: ***********
⠦ Initializing filesystem...✓ Connected as @tas_jr_bot
✔ Mounted at /mnt/tg-drive

📁 Telegram storage is now a folder!

   Commands you can use:
   ls /mnt/tg-drive          # List files
   cp file.pdf /mnt/tg-drive/  # Upload
   cat /mnt/tg-drive/file.txt  # Read
   rm /mnt/tg-drive/file.pdf   # Delete

Press Ctrl+C to unmount

but when i do ls /mnt/tg-drive, i'm getting this

$ ls /mnt/tg-drive
ls: reading directory '/mnt/tg-drive': Input/output error

[ixchio]

Fixed in v3

The mount now builds real folders from logical paths so nested sync files no longer become invalid root entries

Lookups and rename operations use exact logical paths and the regression suite covers nested sync paths plus sixty thousand flat entries

Closing this one thanks for the clean report

[jhnnr]

Hi updated to v3 but the issue is still there, tho I can ls into that mount directory. I can't seem to open the folder from the UI it just looks like this.

also was able to make an smb network share for that folder but can't open it.

[ixchio]

You are right this is a second mount interoperability bug so I reopened the issue

Version 3.0.3 now implements the filesystem statistics directory handles access checks sync calls stable inode metadata and extended attributes used by desktop and Samba clients

For the local file manager upgrade TAS stop the old mount and remount normally

For Samba add this exact line to /etc/fuse.conf

user_allow_other

Then mount with shared access enabled

npm install -g @nightowne/tas-cli@3.0.3
tas mount /mnt/tg-drive --allow-other

Shared access stays opt in because it exposes the mount to other local users subject to Unix permissions

Please send the tas doctor output and confirm whether both the local UI and the Windows share open

I will keep this open until your real host confirms it

[jhnnr]

Here's tas doctor

🩺 TAS Doctor — System Health Check

  ✓ Node.js 26.10.0
  ✓ Data directory: /home/jhnnr/.tas
  ✓ Config v2 (encrypted token)
  ✓ Storage chats configured: 1
  ✓ Database: 3885 files, 1.69 TB total
  ⚠ 32614 legacy chunk(s) exceed the hosted 20 MB getFile limit — They may require a local Bot API server to recover; new uploads use 19 MiB payloads
  ✓ FUSE runtime: mount → readdir → unmount passed
  ✓ Disk space: 268G free (40% used)
  ✓ Encryption: AES-256-GCM, PBKDF2-SHA512 600,000 iterations
✓ Connected as @tas_jr_bot
  ✓ Telegram connectivity: 1/1 bot(s) OK

  1 warning(s). System is functional.

the shared folder is not working as intended but when I am trying to access a video file I get this error

🗂️  Mounting Telegram as filesystem...

✔ Enter your encryption password: ***********
✔ Mounted at /mnt/tas

📁 Telegram storage is now a folder!

   Commands you can use:
   ls /mnt/tas          # List files
   cp file.pdf /mnt/tas/  # Upload
   cat /mnt/tas/file.txt  # Read
   rm /mnt/tas/file.pdf   # Delete

Shared access is enabled; Unix file permissions still apply
Press Ctrl+C to unmount
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: No chunks found
Read error: ETELEGRAM: 400 Bad Request: file is too big
Read error: ETELEGRAM: 400 Bad Request: file is too big
Read error: ETELEGRAM: 400 Bad Request: file is too big

tho I am able to access file that are not chunked.

[ixchio]

TAS Storage Recovery Update

Thanks, this makes the remaining problem clear.

Current Status

The mount itself is working now.

The remaining issues are with older storage data:

• No chunks found means some old interrupted uploads left file records without chunk metadata.
• file is too big means legacy chunks are above Telegram's hosted Bot API 20 MB download limit.

Your doctor output confirms that this affects a large part of the older storage.

TAS Issue Found

I also found a TAS problem in my previous advice.

Config v2 does not yet expose a proper local Bot API endpoint setup, so telling you to use one was incomplete.

Fix Planned for the Next Release

I am fixing this for the next release within four days.

The release will add:

• Safe repair for broken zero-chunk records
• Clearer doctor output
• Supported local Bot API endpoint configuration
• Recovery support for oversized legacy chunks

I am keeping this issue open until the full recovery flow is confirmed on a real host.

Thanks for the detailed report.

[ixchio]

Thanks this isolates the remaining legacy read failures

The mount and shared access path are starting correctly now

No chunks found comes from old interrupted uploads that left an index record without its chunk metadata

File is too big comes from legacy chunks above Telegram hosted Bot API 20 MB download limit

I fixed both recovery paths for the next version and it will release in four days as v3.0.4

It adds local Bot API endpoint setup for the bot that owns legacy chunks

It adds doctor output for zero chunk records incomplete chunk sets and oversized chunks

It hides incomplete records from mounts so desktop and SMB clients stop retrying broken files

It adds a safe index repair command that only removes zero chunk local records after confirmation

I am keeping this issue open until you can test v3.0.4 on your host and confirm the local UI Windows share and legacy video reads