TV Series rename move entire Plex library

[adaminca]

I purchased a year license in order to get my Plex server files cleaned up. My files are stored on a NAS and I mount the shared folder as needed on remote systems. The folder structure is quite typical for a Plex system as shown below. I used Filebot to clean up Television shows

Multimedia
|_Plex
..|_ Movies
....|_Movie 1
....|_Movie 2
.
.
|_Television
..|_Series 1
....|_Season 1
....|_Season 2
.
.
..|_Series 2
....|_Season 1
....|_Season 2
.
.

I had great success using Filebot to organize several TV series using automatic lookup results for those already is decent shape and manual list matching for those is worse shape. Unfortunately, this success ended when working with the final series, Mission: Impossible, I had not organized.

I had this series in the /tmp folder and intended to have Filebot rename the files and folder then I would move them to my Plex shared folder. I kept getting errors related to the SNAP not being able to create the folders required for the renaming. I decided to move the files first then use Filebot since this what previously worked.

I had to modify the preset for Plex because the folder format was not desirable. I received an update message for Filebot before I started this and I believe the presets must have changed in conjunction with the update. Once I modified the preset the preview pane looked fine so I ran the rename.

There were no error messages during the rename process but I was unable to locate the files when the process completed. The revert function did not work either since the files were not present in the location shown in the preview panel. I was shocked and thought I lost my entire Plex library (Movies, Television, Music, and Audio books)!

I had to hunt for the files and was fortunate to have found them. The Plex folder and all nested folders with content has been moved into a folder named ".Trash-1001". The Mission Impossible files were all renamed in this location but folder structure was altered such that it broke all my automation and my Plex server until I moved everything back where it belonged. The file structure now looked like:

Multimedia
|_.Trash-1001
..|_Plex
....|_ Movies
......|_Movie 1
......|_Movie 2
.
.
....|_Television
......|_Series 1
........|_Season 1
........|_Season 2
.
.
......|_Series 2
........|_Season 1
........|_Season 2
.
.

The rename operation should have been constrained to the Television/Show folder and I am struggling to understand why the program would have moved the entire folder hierarchy, especially because the only files specific to wok on were the Mission Impossible series files.

Here is information I am hoping will be helpful to determine the root cause:

System Information
https://pastebin.com/8d5psDLe

Logs
https://pastebin.com/vJNrKxN8

File rename dialog

[rednoah]

I was not able to view the logs. Presumed download button was a reload button... My bad. Please repost, or PM me the logs if you don't want to post the publically.


I have no idea how any configuration could move files to a newly created .Trash-1001 folder though. This makes no sense to me. There's more going on than just FileBot doing FileBot things. The history screenshot suggests that FileBot moved files correctly, so something unexpected happened after that.


Are you able to reproduce the issue?


What is your custom format? If you re-organize your files then absolute formats are strongly recommended, so that FileBot doesn't have to guess what you're trying to do. This is unlikely to be related to the issue at hand though.


If you use SNAP to install software then you will want to be aware of SNAP confinement which prevents SNAP applications from arbitrarily accessing your file system, i.e. SNAP application cannot access /tmp and other system folders by design. I would generally recommend installing (trusted) software via apt install instead. This is also unlikely to be related to the issue at hand though.

[adaminca]

I haven't used Filebot since the issue occurred. I would need to work within the Plex library folders again to try and reproduce the problem but do not want to tempt fate until I better understand what occurred.

I sent you files via DM.

[rednoah]

I got the log. Unfortunately, the log doesn't say anything about moving files / folders to the Trash. So I have no idea and no clue. This kind of thing seemingly hasn't happened to anyone else, and it does seem like the kind of thing someone would report if it happens...


This error message just means FileBot couldn't move files into the target file path specified by your custom format, which is expected if the target path is invalid:

Code: Select all

SEVERE: MOVE: Cannot create parent folder: /Media/TV Shows/Mission - Impossible {tmdb-4357}/Season 01: Access Denied: /Media (rwxr-xr-x 0:0 ) [Snap Confinement: Strict]

This error message just means FileBot couldn't store xattr after the the file was moved, likely because the target file system does not support xattr:

Code: Select all

WARNING: Failed to write xattr key: net.filebot.metadata: /media/Multimedia/Plex/Television/TV Shows/Mission - Impossible {tmdb-4357}/Season 07/Mission - Impossible - S07E22 - Imitation.mkv: Error writing extended attribute 'net.filebot.metadata': Operation not supported

If you could reproduce the problem, then I could try to reproduce the problem myself, or at least reproduce it with debug logging on your end and see if there's any clues...

[adaminca]

Appreciate the response although not what I expected. The problem occurred immediately after a Filebot version update (I was prompted to update after starting the program). I suspect that is the root cause as it worked fine prior to the update. Almost seems lithe the trash directory may have been used as a temporary location while working with files but I am stumped as to why it would have worked with the folder structure two levels higher. This also leads to a question as to why it had rights to create the trash folder but nit the intended directory as they were both within the same mount heirarchy.

I will remove the program and reinstall to see if that resolves the issue.

[rednoah]

The latest update is almost certainly unrelated. It's as good a start as any, might be a clue, but the next step would be being able to reproduce the issue with the latest version / not being able with a previous version, to confirm that that theory indeed holds merit.


/Media/TV Shows and /media/Multimedia/.Trash-1001 are notably not the same. /Media is reserved for mount points, so not being able to create your own folder there makes sense. /media/Multimedia is the mount point, so anything inside that folder should be fine.


.Trash-1001 is a Linux Desktop standard. If you delete files via Gnome / KDE / etc then files will be moved to the top-level .Trash folder. The 1001 UID suggests that the .Trash folders was added by that user. 1001 is probably your user ID so that doesn't give is any clues.


I have reviewed the code and FileBot doesn't actually call "Move to Trash" all that often. That function is only ever called in the GUI if you do Double-Click <Original Files item> ➔ Move to Trash or History ➔ Right-Click <item> ➔ Revert so neither of these calls can happen automatically in the background and neither can be used to accidentally delete folders even if you tried.


One thing of interest would be to do Double-Click <Original Files item> ➔ Move to Trash (with SNAP confinement enabled) on purpose with some test file to see what happens. Maybe it'll move the file to a newly created .Trash-1001 folder and we're none the wiser. Maybe it'll fail because "Move to Trash" might not work in a SNAP context. That would give us a clue.


My best guess is that SNAP sandbox / XDG desktop portals strangeness somehow translates some I/O calls to "Move to Trash" somehow. Far fetched, but I've got no better idea either. The other thing would be an accidental press of the DEL key when the Plex folder was selected. Far fetched, but user errors (accidental; thus without intent or memory) do happen from time to time. But without clues, any theory without supporting evidence is probably wrong.