[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

12 hours ago, dlandon said:

Please update to 6.12.10-rc.1.  It should fix this issue.  It's available on "Next".

 

 

I no longer see this issue when rsyncing to a remote smb share on 6.12.10-rc.1. 

[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

2 minutes ago, anotherdud3 said:

I'm using Unassigned Devices plugin already, but freefilesync still can't see the remote share, remotes in the unraid file manager is there and see the shares but they're not visible in freefilesync, checked multiple places. 

 

It looks like Freefilesync adds /mnt/user as the source storage by default; this won't pick up the remote shares. You'll have to change that to just /mnt, then you'll be able to access /mnt/remotes from Freefilesync. Using /mnt/user will only give your Unraid shares. 

[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

40 minutes ago, anotherdud3 said:

Thanks, I was aware of rsync etc but wasn't sure if it could see smb shares on a remote device, freefilesync couldn't so had to go sftp and go that way, now chugging along. 

 

You can transfer to a share using rsync/Freefilesync, you just have to mount the share to Unraid first. Kinda like a mapped drive in Windows. You can use the Unassigned Devices plugin to take care of the mounting, then rsync or use Freefilesync for the transfer.

[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

17 minutes ago, EvilNuff said:

For those downgrading I only see the option to downgrade to .5, are you downgrading to .5 and then re-upgrading to .8?  Or is there someway to just downgrade to .8?

 

I downgraded directly to .8.

[[6.12.9] CIFS: VFS: directory entry name would overflow frame end of buf]

I am also seeing this error when I rsync my data to my backup machine. Downgraded without issue. 

[Dockers wanting to update, but don't in the end?]

By manually doing this fix now do we POTENTIALLY create side effect issues when issue is officially updated and pushed as a update to Unraid? Any known reason this wouldn't be advisable to immediately do?

 

The change does not persist through reboots, so it won't cause any lasting harm.  Once unraid gets updated we'll reboot and everything will be back to normal.

[Dockers wanting to update, but don't in the end?]

I just opened the terminal (ssh/telnet works too), cd /usr/local/emhttp/plugins/dynamix.docker.manager/include and typed nano DockerClient.php  The line of code is about half way into the file.  You do not need to stop the array or do anything else.