Musescore and NFS volumes

• Aug 17, 2018 - 02:44

Musescore cannot see my NFS mounted volumes which are mounted on my Linux machines.
Is Musescore completely NFS unaware or is there something I am missing.
The volumes are mounted and every user account can access them from terminals, File Managers, browsers and all applications can load and save files to and from from NFS volumes. Only Musescore seems blind to NFS and do not even list them when opening or saving a file..
This usually happens if a program was written for Windows and then ported to Linux. Is this the case or what is the problem ?


Comments

In reply to by retnev

I'm not on Linux, so no NFS either. However, whatever filesystem a file is on, this is not MuseScore's business and transparent to it. Also there is no code in MuseScore that would explicitly deny NFS.
And actually Musescore was originally developed on and for Linux and got ported to Mac and Windows.

In reply to by Jojo-Schmitz

If you are not a Linux user then you would not know what this is about. EVERY other application can access the filesystem and it is transparent on Linux. ONLY musescore ignores the NFS volumes. The problem lies how musescore access the filesystem.
This is usually an old QT troltech problem as I can remember.
Does musescore use QT Troltech as a library ?

In reply to by retnev

Well, the Musescore developers sure won't look into and fix Qt code. If there really is a bug in Qt reg. NFS, which a quick Google search didn't give hints at, do you have further information about that?
If there is, and there are possible workarounds in how Musescores uses the Qt libs, that might be am option.

I would prefer Linux users comment on this thread to make it more to the point:
Are there any Musescore users on Linux using NFS on the group ?
Can you verify the problem ?
Thanks

I have been a Linux user on and off, a MuseScore user for somewhat longer, and an NFS user going way way way back, but can't recall ever trying that specific combination before (MuseScore on Linux using NFS), so i can't address that.

I can speak to the specific question you asked about whether MuseScore was written for Windows then ported to Linux. Answer: no, precisely the opposite. MuseScore began life on Linux and was only ported to Windows years later. But in any case, that shouldn't matter. MuseScore uses the Qt libraries, which is probably the most common way for cross-platform applications to be developed. If Qt supports NFS on a given platform, then probably so does MuseScore. I don't see anything in a quick search to suggest it doesn't, nor can I recall any other Linux users (besides you a few months ago) reporting problems here. So I have to assume it does work and it's just some configuration issue on your system. Have you carefully checked the left panel of the file dialogs to be sure you are accessing all of the available drives? I do recall there being some non-obvious things about how that works when I needed to access a volume mounted in some unusual way, but it was there when I expanded everything on the left.

In reply to by Marc Sabatella

Marc, thank you for the response.
I installed on several systems, same issue, NFS Volumes ignored.
I can migrate right down the \ directory and still no NFS is shown in the panel when opening or trying to save a file. Absolutely NONE of the 100's of applications running on the systems has any problems with NFS.
ONLY Musescore has problems with NFS and ONLY Musescore.

It definitely doesnt work and it must be an issue off Qt libraries. I had this problem about 10 years or so ago with an application and the problem was with implementation of Qt back then.
I can say 99% sure with this version, that Musescore doesnt access nfs.

On the lighter side: Curious that I am the only person that uses Musescore on Linux with NFS.
Did civilization come to a standstill lately ?

In reply to by retnev

If you mean that MuseScore doesn't show NFS shares in File > Open or File > Save as, It could be due to the use of non native QFileDialog on Linux. You should be able to set nativeDialogs to "true" in ~/.config/MuseScore/MuseScore.ini (or something similar) to run MuseScore with native dialogs.

In reply to by retnev

If it's a general issue with Qt, then LibreOffice at least should be experiencing the same. Probably other of the 100's of application you use - Qt is quite common in the Linux world. The non-native dialogs may indeed be masking your ability to see these filesystems in the dialogs. I wonder what happens if you just enter the pathname manually?

In reply to by Marc Sabatella

If I save a file and enter the pathname to the nfs folder NOTHING is saved in the nfs directory.
In fact if I try to resave it it comes up with the previous filename and nfs directory path, but it dropped the "/" in front of the nfs volume, which is a serious problem. I assume since it saved my previous path, it is clear that it saves it without a / in front as the nfs volumes lives in / and without that it will never see the nfs volumes or save for that matter.

Just an observation about how musescore obviously "saved" my path wrong.
Attached 1.png as I tried to save it.
Attached 2.png as Musescore remembered it (clearly wrong)

Attachment Size
1.png 13.68 KB
2.png 12.65 KB

In reply to by retnev

That looks very stange. But since you consider yourself a knowlegeable linux user how about some trivial d ebuging? Open up a terminal, change to your NFS-mounted directory and run 'sudo fatrace -c'.
Then try to access a file in this directory from within MuseScore and watch the output in the terminal.
BTW, what's the version of MuseScore you are running? From the distro or home-made or from an App-Image?

In reply to by rmattes

Did you figure out why musescore incorrectly remembers a save path ? That is pretty serious as it may indicate a backslash-less path sent to the operating system which clearly will cause this problem !

I create a new file in musescore then save it to the nfs volume /public by entering it in cl.
musescore completes save without error message. However the file is not there on the volume so musescore fails to alert the user of an error saving. ( it should at least check !! )

Doing fatrace on the client started before the above file creation and save...
root@ter01:/public# sudo fatrace -c
Absolute Nothing......
root@ter01:/public#

I obviously had to close down all other applications which uses nfs access.
It was libreoffice or other applications which created events like
root@ter01:/public# sudo fatrace -c
ls(2542): O /public
ls(2542): R /public
ls(2542): RC /public
root@ter01:/public#

In reply to by retnev

Then it's time for ye olde 'strace'.

$ strace -o <pid-of-your-mscore> -o trace.log

Also, after closing MuseScore, do a:

grep lastSaveDirectory ~/.config/MuseScore/MuseScore2.ini

Look at the log file, this will tell you where mscore actually tries to save the file (and probably succeeds,otherwise you'd see an error message).
Did you figure out why musescore incorrectly remembers a save path ?
No, but as I said, it's working here.

In reply to by rmattes

just irritating pedantics, but I guess you meant strace -p .
I will see what I get.

Right there is the problem
root@ter01:/public# strace -p 5199 -o trace.log
strace: Process 5199 attached
^Cstrace: Process 5199 detached
root@ter01:/public# cat trace.log |grep -i 1.mscz
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a7220) = -1 ENOENT (No such file or directory)
stat("//home/user01/Documents/MuseScore2/Scores/public", 0x7ffe563a71e0) = -1 ENOENT (No such file or directory)
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a6fb0) = -1 ENOENT (No such file or directory)
stat("//home/user01/Documents/MuseScore2/Scores/public", 0x7ffe563a7120) = -1 ENOENT (No such file or directory)
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a7340) = -1 ENOENT (No such file or directory)

CLEARLY Muscore incorrectly expands the nfs foldername to mean a subfolder of the home directory musescore folder
/home/user01/Documents/MuseScore2/Scores/public/ and not /public/1.mscz which I entered.
This EXACTLY why it remembers public/filename and not /public/filename, the latter which is the nfs volume.
This is clearly a Musescore issue as I entered /public/a.mscz which is an nfs folder and Musescore then goes and try to find a directory public in my HOME directory.

In reply to by retnev

Slow, slow. I just checked: NFS file access works flawless here, I can create new files, save, open and 'save as' without any problems (both, server and client are Linux boxes, on different networks).
Why shouldn't it work? Userspace file system access on Unix and Linux always passes through the operating systems virtual filesystem layer, programs would have a hard time even finding out on what filesystem a file actually resides.
Anyway: there's a good chance that you miss-configured your NFS setup. Care to share?

In reply to by rmattes

Good to know it works at least for someone.
However, the nfs server serves 6 remote terminals on the network with no NFS issues.
Runs other supposed Qt based applications such as Libreoffice (which was mentioned) without any hickups over remote X-sessions and natively and accesses NFS flawlessly.
Samba works with it too for the unfortunate do$e machine that needs to be connected.

ONLY Musescore has this problem.
Also see the path error Musescore interprets my nfs volumes as in a post above.
That is an obvious sign of trouble.

Which nfs config files do you want ?

In reply to by retnev

"Good to know it works at least for someone."
Hmm, looking at this forum at least it seems more like you are so far the only one with this problem...
As for the config files - there really are only two interesting bits: the line in the servers /etc/exports where you export the file system and the mount options on the client box (and, aof course the NFS version you are using).

In reply to by rmattes

Rather than the nfs sever, I would guess that Qt has nsBIND problems.
I can now remember that was an issue about 10 years ago using Qt in a development when it still was Troltech.
They were sloow to fix trouble, so the problem might still persist.

On the nfs server running
nfs-common (1:1.3.4-2.1ubuntu2)
nfs-kernel-server (1:1.3.4-2.1ubuntu2)

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=17.10
DISTRIB_CODENAME=artful
DISTRIB_DESCRIPTION="Ubuntu 17.10"
NAME="Ubuntu"
VERSION="17.10 (Artful Aardvark)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 17.10"
VERSION_ID="17.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=artful
UBUNTU_CODENAME=artful

One of the 15 volumes that cannot be accessed by Musescore but available on ALL other applications. Musescore is the SOLE application with nfs trouble.
On the NFS -server /etc/exports
/public *(rw,no_root_squash,sync,secure,subtree_check)

mount on client is just
mount -t nfs nfsserver:/volume pathtoclientvolume

Cant see why this can be the issue.

In reply to by retnev

"Rather than the nfs sever, I would guess that Qt has nsBIND problems."
Please, this is rubbish. Neither Qt nor MuseScore have anything whatsoever to do with the NFS protocol.
That's all handled by your kernel. Pretty much the only way an application might even notice the underlying file system type is if it (wrongly) expects local file system locking semantics (a problem that tends to show up with databases and servers. I strongly doubt that MuseScore has such problems).

"I can now remember that was an issue about 10 years ago using Qt in a development when it still was Troltech. They were sloow to fix trouble, so the problem might still persist."
Since you seem to have more info on this than anyone else here would you care to share some information? My Google foo found nothing relevant ....

/public *(rw,no_root_squash,sync,secure,subtree_check)
Let's really hope this is not your actual configuration - that's a giganormous security hole you have.
/no_root_squash/ on a world-mountable share? I guess you already tried the obvious no_subtree_check, esp. since subtree_check doesn't make sense here?

What does the 'fatrace' logging show?

In reply to by rmattes

It's fine, your trash is my gold.
I used Qt years ago with a company with a troltech license. In my opinion it was the worst toolkit ever. The craziest bind problems. They seemed to try and implement their own bind daemons under different names and mimic all other protocols to become platform independent. I really don like it and will never use it. it's a ratsnest. Probably why troltech got sold.

As for mounting nfs on ..
The best thing I ever did.
As soon as someone try something the system locks up.
I started to use it like this years ago and wont go back.

Dont drink all the coolaid......
What is detestible for one is great for another and for me it worked great for almost 20 years.
Never a breach.
But, I guess you believed that SELinux was a good thing too....?
Maybe you can google and see how I exposed it about 8 years ago for what it was.
That is a gaping security hole on steroids and to add the entire SUDO garbage is nothing else than to make it easier for hackers. Why the Linux community fell for that hook-line & sinker I dont know. It is easy to see the malicious intent in order to suggest something like SUDO. They in effect transferred the root password to a user account and password. I mean really !?
Userspace is much more promiscuous and you get a user's password much easier than a root password. (Therefore it was peddled as Koolaid).
First thing I do is to rid my systems of sudo, so that there is no chance anyone can get root access through a user account. By default systems now install with a sudo user. What a gaping security hole on every general users system. This was all invented to circumvent the root user account.
Second I mount nfs on / and have good reason to do it from experience.
And so on.
YOUR security is not MY security and your opinion is just that.
An opinion.
Vice Versa.

I didnt get a response after clearly showing that Musescore has the problem on Linux for misinterpreting nfs volumes present and try to save data to them in the nfs folder in the user's account. As I mentioned before "/public" is the nfs volume used.
In another post I also showed that Musescore incorrectly remember path names by ommiting the / from nfs directory paths. It returns NOT what was entered.

Since I dont get a response, should I post it in bug tracker ?

Right there is the problem
root@ter01:/public# strace -p 5199 -o trace.log
strace: Process 5199 attached
^Cstrace: Process 5199 detached
root@ter01:/public# cat trace.log |grep -i 1.mscz
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a7220) = -1 ENOENT (No such file or directory)
stat("//home/user01/Documents/MuseScore2/Scores/public", 0x7ffe563a71e0) = -1 ENOENT (No such file or directory)
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a6fb0) = -1 ENOENT (No such file or directory)
stat("//home/user01/Documents/MuseScore2/Scores/public", 0x7ffe563a7120) = -1 ENOENT (No such file or directory)
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a7340) = -1 ENOENT (No such file or directory)

CLEARLY Muscore incorrectly expands the nfs foldername to mean a subfolder of the home directory musescore folder
/home/user01/Documents/MuseScore2/Scores/public/ and not /public/1.mscz which I entered.
This EXACTLY why it remembers public/filename and not /public/filename, the latter which is the nfs volume.
This is clearly a Musescore issue as I entered /public/a.mscz which is an nfs folder and Musescore then goes and try to find a directory public in my HOME directory.

Reply

In reply to by retnev

NFS is legendary for being cantankerous talking with linux ....

I've had issues with different applications and different versions of NFS I will be surprised if it is a MuseScore issue.

Wonder if you have tried to mount with following format mount -t nfs -o umask=0022,gid=XXX,uid=YYY 192.168.1.5:/NFS_SHARE /mnt/nfs_repo/ where the ipaddress of your repo is replaced with the 192....

In reply to by Ron Southworth

I am a certified linux sysadmin.
I know how nfs work.
AND
There is about 1000+ processes on this server that uses NFS all WITHOUT any trouble, The only application that has problems with NFS is Musescore and from the debug in my last post the reason is clear..
Musescore ignore the NFS mounts which are mounted and used by countless applications.,

The problem is somewhere with Musescore's interpretation of NFS through Qt. It is most likely triggered by something.
There is no way an NFs volume is mounted and can be accessed by everything on a Linux client even Libreoffice which purportedly also uses Qt, and I have NO problem with that.

It is only Musescore, and the wrong path saved by musescore when you enter it is a clear indication that Musescore is at fault as it drops the / from the path which will disallow it from seeing the NFS mount and will default to the NFS directory name in the user account. Simple.
Probably a misconfiguration of the Qt libraries, but it is no my place to figure out what is wrong in Musescore.

Do you still have an unanswered question? Please log in first to post your question.