Problem with SAVE

Bug
1

Manjaro Linux (up to date)

Shotcut version ARCH-22.04.25 - 64 bits

The SAVE problem is only when editing files from my NAS (Network Attached Storage)

  1. Open Shotcut
  2. Set folder and file name on a directory on my NAS (everything saves OK at this point)
  3. Modify my project and try saving again, I get the error “There was an error saving. Please try again.”
  4. Try SAVE AS on my NAS in the same directory but different filename and it works
  5. Modify project again and try saving, I get the error “There was an error saving. Please try again.”

If I copy the structure to the local disk on my computer, everything works fine. So there is a problem with Shotcut saving to network drives.

All other software work fine with my NAS and it’s not a permission problem (I checked)

I know of another software (Calibre) that has the same problem and has never been fixed

Do not hesitate if you have any questions

Thanks

2

If the permissions are correct then the problem is possibly due to file locking issues.

Regarding your Calibre problem, Calibre Support advise against putting the library on a network drive. See: Frequently Asked Questions — calibre 5.44.0 documentation

3

I use a NAS on Linux all the time using NFS and never have a problem. You did not provide enough info to reproduce it since “NAS” is not enough information.

4

Hi,

My NAS is Open Media Vault 5 and I don’t use NFS because I have had to many problems with it on some devices. I use Samba (up to date) for file sharing. Like I mentioned, all my other software may it be Gimp, Thunderbird, OpenShot, Audacity, Handbrake you name it, they all work perfectly with my NAS.

Everything with Shotcut works perfectly (save as, open, importing media and exporting too my NAS) but for some odd reason, the save function generates an error, but when using the local drive, It’s fine.

I only gave calibre as a reference, but the problem still exists and the solution is to not use a NAS…

Thanks

5

Weird as I use SMB from my Windows and macOS to the machines with no problem either. The code uses the QSaveFile API, which does some things to ensure a more reliable save operation that might be affecting some situations.

6

Do you know of any other software that uses QSaveFile so that I could do some testing?

7

Have you tried the portable linux package from here?

8

It sounds like there is a problem in the setting up of shared folders on your Open Media Vault NAS.

The general usage of QSaveFile is:

  • Call QSaveFile (this creates a temporary file);
  • Open the file;
  • Write to the file;
  • Call commit();

Commit() renames the file, probably using the Stdio rename function. If the name of the new file is that of an existing file, the function may either fail or overwrite the existing file, depending on the specific system and library implementation… This is probably where your NAS is giving an error.

To test:

  • Create a file “File1” on the NAS;
  • Create another file “File2” on the NAS;
  • enter the command “mv File1 File2”
9

Tested the commands from same computer to the same NAS and the same directory and everything works. Must be something else. Thanks

10

Today, I mounted my file server via SMB like so on my Linux workstation like so:

$ sudo mount -t cifs -o uid=ddennedy,rw,vers=3.0,credentials=/root/.examplecredentials //fileserver/storage net/smb

But I did not reproduce the problem. I think someone else who has the problem will need to debug it: see Controller::saveXML() in mltcontroller.cpp.

11

I just would like to report to you that I seem to be having the same kind of problem. I am running Shotcut 22.01.30 on Lubuntu 22.04.3 LTS. I am having a Windows share served by an Asustor NAS.

I’m a complete noob who has just started using Shotcut just a few days ago. I have not really looked into this problem yet, but I know it is happening with me for sure. If there’s an easy fix, I would love to know.

Thanks!

12

Now I know when I mount the Windows share with rclone, I do not get the same problem.

13

I have previously experienced this same problem in LibreOffice when using mount -t cifs on a Linux Mint client to a Linux Mint Samba server. I am pretty sure the problem has to do with Samba/CIFS optimistic file locking and has nothing to do with Shotcut itself. I changed my mount options when it happened, and there hasn’t been a lock issue in recent memory. I added:

nounix,serverino,mapposix

I am the first to admit that those options shouldn’t be directly related. But the mount seems to be working fine for now, so I moved on with life.