Welcome to the forum, Guest

TOPIC: SQL issues on NAS

SQL issues on NAS 8 years 10 months ago #1784

7o9

Hello my friends,

I noticed there is a similar thread in the Bugs subforum but I decided to create a new thread because my issues seem to be different.

When I create a library on my local drive everything works fine. Creating the library on my mounted network share results in an empty .ydb file. This is independend of the files in the library folder. The files in the folder are created but can't seem to be written.

I tried debugging and was able to find the point where it differs from creating the library on the local drive.

in data_base_management.cpp in createTables:
    QSqlQuery queryFolder(database);
    queryFolder.prepare("CREATE TABLE folder ("
                        "id INTEGER PRIMARY KEY,"
                        "parentId INTEGER NOT NULL,"
                        "name TEXT NOT NULL,"
                        "path TEXT NOT NULL,"
                        //new 7.1 fields
                        "finished BOOLEAN DEFAULT 0,"   //reading
                        "completed BOOLEAN DEFAULT 1,"  //collecting
                        //--
                        "FOREIGN KEY(parentId) REFERENCES folder(id) ON DELETE CASCADE)");

   
    success = success && queryFolder.exec(); // <-- here
    
    QString err = queryFolder.lastError().text(); // "database is locked unable to fetch row"

After exec() when creating on local drive the .ydb file is created with content. On my nas the file is empty (0kb) with a .ydb-journal file next to it.

Do you have any idea what might cause this? Unfortunaly I have no experience with sql,
The administrator has disabled public write access.

SQL issues on NAS 8 years 10 months ago #1785

selmf

Offline

Developer

Posts: 636

Thank you received: 135

Karma: 18

Hi 7o9,

thank you very much for taking the time to debug this and making such an detailed post. I'm not sure what's causing this either, so we'll need to run some test in order to reproduce the issue. Could you provide us with the following info?

- Linux distribution
- how did you install YACReader?
- how and where do you mount your NAS on your machine? (full path, mount command)
- the output of "ls -la" in the .yacreaderlibrary folder

Best regards,

selmf
My answers are not necessarily official YACReader statements but mostly represent my own opinion in technical matters.
The administrator has disabled public write access.

SQL issues on NAS 8 years 10 months ago #1786

7o9

Thanks for your reply,

- distri and Kernel: 4.1.6-1-MANJARO x86_64

- via package manager. Version is 8.0-2. For debugging I used the latest source from bitucket. Both show the same problem.

- fstab:
//192.168.2.86/media/ 			  /mnt/media     cifs    user=xxx,noauto,users,uid=1000,gid=100,file_mode=0777 0 0
mount with "sudo mount //192.168.2.86/media"

-
$ ls -la
total 0
drwxr-xr-x 2 xxx users 0 Sep  8 22:23 .
drwxr-xr-x 2 xxx users 0 Sep  8 22:23 ..
drwxr-xr-x 2 xxx users 0 Sep  8 22:23 covers
-rwxrwxrwx 1 xxx users 0 Sep  8 22:23 library.ydb
The administrator has disabled public write access.

SQL issues on NAS 8 years 10 months ago #1787

selmf

Offline

Developer

Posts: 636

Thank you received: 135

Karma: 18

According to the Archlinux Wiki which should also be relevant for Manjaro using uid and guid in the mount options "[...]may cause input ouput errors in programs that try to fetch data from network drives."

wiki.archlinux.org/index.php/Samba


Could you check if the problem is still present when you do a manual mount without fstab as described in the Archlinux Wike article?
My answers are not necessarily official YACReader statements but mostly represent my own opinion in technical matters.
The administrator has disabled public write access.

SQL issues on NAS 8 years 10 months ago #1788

7o9

I mounted with "sudo mount.cifs //192.168.2.86/media /mnt/media/ -o user=xxx" same results. I also tried mounting a different network share and mounting as admin and starting YAC as root. Sadly didn't work either. Something seems to lock onto something. I can delete the .yacreaderlibrary folder while the programm is running when I use a local drive. But with the network share it says the resource is busy.
The administrator has disabled public write access.

SQL issues on NAS 8 years 10 months ago #1789

selmf

Offline

Developer

Posts: 636

Thank you received: 135

Karma: 18

Looks like there is a problem with sqlite's file locking behavior. Please try adding the mount parameter "nolock" to your fstab or manual mount options and retry.
My answers are not necessarily official YACReader statements but mostly represent my own opinion in technical matters.
The administrator has disabled public write access.
The following user(s) said Thank You: 7o9

SQL issues on NAS 8 years 10 months ago #1790

7o9

Great it's working now! :)

Sorry if this was an obvious problem. I'm rather new to linux.

Thanks for your help!
The administrator has disabled public write access.

SQL issues on NAS 8 years 10 months ago #1791

selmf

Offline

Developer

Posts: 636

Thank you received: 135

Karma: 18

Nice to hear that it is working again B)

No, it wasn't an obvious problem. It's rather a problem that can occur in some cases when a sqlite database is located on a network filesystem. Your feedback, especially the part where you mentioned the lock on the database file helped me to track down the solution I gave you and might help others suffering from similar problems. So thank you for reporting the issue :)
My answers are not necessarily official YACReader statements but mostly represent my own opinion in technical matters.
Last Edit: 8 years 10 months ago by selmf.
The administrator has disabled public write access.

SQL issues on NAS 1 year 2 weeks ago #7660

zuboratoon

Offline

Fresh Boarder

Posts: 1

Thank you received: 1

Karma: 0

Just because I just ran into the same problem and was confused why there is no 'nolock' option: It has been removed and the equivalent option is 'nobrl' (which resolved the issue for me).
The administrator has disabled public write access.
The following user(s) said Thank You: Luis Ángel
Powered by Kunena Forum