Can you show the content of XEEN1.CUE?

I can assure you that CUE files work just fine with DOSBox on Linux, so I'm afraid it looks like something must be wrong with your setup. Possible reasons I can think of (other then file naming and permissions)
- spaces or other special characters in filenames
- unsupported track format (e.g. mp3 tracks)
- invalid path specified in CUE file

As a general rule, CUE/BIN and any audio tracks should all be stored in the same directory. And the CUE file should ONLY have the filenames without paths specified.

Thanks for the reply!
Here is the content of the CUE file:

FILE "XEEN1.IMG" BINARY
TRACK 1 MODE1/2352
INDEX 1 00:00:00
TRACK 2 AUDIO
INDEX 0 05:46:13
INDEX 1 05:48:13
TRACK 3 AUDIO
INDEX 0 08:19:52
INDEX 1 08:21:52
TRACK 4 AUDIO
INDEX 0 08:39:58
INDEX 1 08:41:53
TRACK 5 AUDIO
INDEX 0 09:24:04
INDEX 1 09:25:72
TRACK 6 AUDIO
INDEX 0 09:49:51
INDEX 1 09:51:58
TRACK 7 AUDIO
INDEX 0 10:34:11
INDEX 1 10:36:18
TRACK 8 AUDIO
INDEX 0 12:48:66
INDEX 1 12:50:64
TRACK 9 AUDIO
INDEX 0 13:04:26
INDEX 1 13:06:19
TRACK 10 AUDIO
INDEX 0 13:16:41
INDEX 1 13:18:40
TRACK 11 AUDIO
INDEX 0 14:49:24
INDEX 1 14:51:31
TRACK 12 AUDIO
INDEX 0 15:48:14
INDEX 1 15:50:13
TRACK 13 AUDIO
INDEX 0 16:06:65
INDEX 1 16:08:64
TRACK 14 AUDIO
INDEX 0 17:05:06
INDEX 1 17:07:03
TRACK 15 AUDIO
INDEX 0 17:47:08
INDEX 1 17:49:08
TRACK 16 AUDIO
INDEX 0 17:53:31
INDEX 1 17:55:33
TRACK 17 AUDIO
INDEX 0 21:07:62
INDEX 1 21:09:64
TRACK 18 AUDIO
INDEX 0 22:42:49
INDEX 1 22:44:56
TRACK 19 AUDIO
INDEX 0 23:16:58
INDEX 1 23:18:65
TRACK 20 AUDIO
INDEX 0 27:08:50
INDEX 1 27:10:43
TRACK 21 AUDIO
INDEX 0 27:16:31
INDEX 1 27:18:30
TRACK 22 AUDIO
INDEX 0 28:35:54
INDEX 1 28:37:51
TRACK 23 AUDIO
INDEX 0 30:23:38
INDEX 1 30:25:46
TRACK 24 AUDIO
INDEX 0 31:08:71
INDEX 1 31:11:04
TRACK 25 AUDIO
INDEX 0 33:33:31
INDEX 1 33:35:28
TRACK 26 AUDIO
INDEX 0 34:53:54
INDEX 1 34:55:52
TRACK 27 AUDIO
INDEX 0 39:05:45
INDEX 1 39:07:51
TRACK 28 AUDIO
INDEX 0 40:04:21
INDEX 1 40:06:24
TRACK 29 AUDIO
INDEX 0 40:51:08
INDEX 1 40:53:11
TRACK 30 AUDIO
INDEX 0 41:32:48
INDEX 1 41:34:42
TRACK 31 AUDIO
INDEX 0 47:34:38
INDEX 1 47:36:36

Is SDL_Sound actually found and compiled in? And if, is this SDL_Sound compiled against SDL 1.2x?

DBob wrote on 2021-06-27, 10:29:

Hello all, […]
Show full quote

Hello all,

The old, never ending story of the CUE/BIN mounting.

Copy code to clipboard

1Could not load image file: /mnt/DOSBOX/GAMES/XEEN/INSTALL/XEEN1.CUE
2MSCDEX: Failure: Invalid file or unable to open.

Meanwhile

• Files naming is correct (upper-lower case)

• 755 mode applied to the files, so they are indeed readable

• Everything is working fine if I mount the very same folder structure from Windows

I also tried to comply a new DOSBox from source, enabling the SDL_Sound, as it was mentioned in some topic, it's required to BIN/CUE handling.
Results were the same with the DOSBox from the distro repo.

You probably already checked for this when you mentioned checking case (presumably for XEEN1.CUE), but just in case (no pun intended), is XEEN1.IMG actually in upper case and actually named XEEN1.IMG , not XEEN1.BIN ?
Also, is SELinux enabled and are you hitting any AVC denials in /var/log/audit.log ?

EDIT : Also, what distro are you using ? I just tested mounting a CUE/BIN in Dosbox -0.74-2 from Debian repo (version 10.10) and it worked fine for me .

Make sure the directory holding the bin/cue files is both executable and readable by the current user.

jmarsh wrote on 2021-06-29, 23:07:

Make sure the directory holding the bin/cue files is both executable and readable by the current user.

Good to check just in case, but in this specific case, the error suggests that the cue file is being found and read, but the referenced img file isn't .

In the limited tests that I have run, the mscdex error is not shown if the cue file is absent (not there or wrong path) or inaccessible (permissions).

Could you provide the output of the following command:

ls -l /mnt/DOSBOX/GAMES/XEEN/INSTALL/

darry wrote on 2021-06-30, 00:04:

Good to check just in case, but in this specific case, the error suggests that the cue file is being found and read, but the referenced img file isn't .

In the limited tests that I have run, the mscdex error is not shown if the cue file is absent (not there or wrong path) or inaccessible (permissions).

The cue file gets opened then each data file listed in it gets stat'd. That requires exec permission on the directory holding them.

jmarsh wrote on 2021-06-30, 23:16:

darry wrote on 2021-06-30, 00:04:

Good to check just in case, but in this specific case, the error suggests that the cue file is being found and read, but the referenced img file isn't .

In the limited tests that I have run, the mscdex error is not shown if the cue file is absent (not there or wrong path) or inaccessible (permissions).

The cue file gets opened then each data file listed in it gets stat'd. That requires exec permission on the directory holding them.

I agree . However, this is likely not the issue in this specific case, as if the cue file and bin/img file are in the same directory and the cue file gets read, but the bin/img file does not, the directory permissions are not the issue . The permissions of the bin/img file could be a problem, but the OP already mentioned checking those (no harm in double-checking).

darry wrote on 2021-07-01, 00:02:

I agree . However, this is likely not the issue in this specific case, as if the cue file and bin/img file are in the same directory and the cue file gets read, but the bin/img file does not, the directory permissions are not the issue . The permissions of the bin/img file could be a problem, but the OP already mentioned checking those (no harm in double-checking).

You apparently missed the part where I said the data files get stat'd. That requires execute permission on the directory. It is not performed on the cue file.

I've been a DOSBox developer for the past three years and have encountered this problem before. Please stop assuming I don't know what I'm talking about.

jmarsh wrote on 2021-07-01, 06:03:

darry wrote on 2021-07-01, 00:02:

I agree . However, this is likely not the issue in this specific case, as if the cue file and bin/img file are in the same directory and the cue file gets read, but the bin/img file does not, the directory permissions are not the issue . The permissions of the bin/img file could be a problem, but the OP already mentioned checking those (no harm in double-checking).

You apparently missed the part where I said the data files get stat'd. That requires execute permission on the directory. It is not performed on the cue file.

I've been a DOSBox developer for the past three years and have encountered this problem before. Please stop assuming I don't know what I'm talking about.

I am not assuming anything about either this issue or about you . I actually tested it . I also included the output in Dosbox when the mount attempt fails due to lack of execute permission on the folder containing the cue and img files . As you can see, the error is not the one that the OP is reporting . I was running Dosbox's graphical output redireced to an X server running under Windows (Xming) while testing, which explains the Windows-like GUI elements .

After running chmod o+x on /srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple and starting dosbox and trying to mount cue :

bob@openmediavault:/srv/dev-disk-by-label-DATA3/DATA3_rw/temp$ strace dosbox 2>&1 | egrep "popple.cue|popple.img"
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", {st_mode=S_IFREG|0664, st_size=769, ...}) = 0
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", {st_mode=S_IFREG|0664, st_size=769, ...}) = 0
openat(AT_FDCWD, "/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", O_RDONLY) = 10
read(10, "FILE \"popple.img\" BINARY\r\n TRAC"..., 8191) = 769
stat("popple.img", 0x7ffc67456550) = -1 ENOENT (No such file or directory)
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.img", {st_mode=S_IFREG|0664, st_size=598318224, ...}) = 0
openat(AT_FDCWD, "/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.img", O_RDONLY) = 11
openat(AT_FDCWD, "/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", O_RDONLY) = 10
read(10, "FILE \"popple.img\" BINARY\r\n TRAC"..., 8191) = 769
stat("popple.img", 0x7ffc67456600) = -1 ENOENT (No such file or directory)
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.img", {st_mode=S_IFREG|0664, st_size=598318224, ...}) = 0
openat(AT_FDCWD, "/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.img", O_RDONLY) = 12

After running chmod o-x on /srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple and starting dosbox and trying to mount cue :

bob@openmediavault:/srv/dev-disk-by-label-DATA3/DATA3_rw/temp$ strace dosbox 2>&1 | egrep "popple.cue|popple.img"
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", 0x7ffcbb26c9b0) = -1 EACCES (Permission denied)
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", 0x7ffcbb26c9b0) = -1 EACCES (Permission denied)

EDIT: Corrected typo

Is SDL_Sound actually found and compiled in?

Yes, it is.

And if, is this SDL_Sound compiled against SDL 1.2x?

I don't know. How can I check it?

EDIT : Also, what distro are you using ? I just tested mounting a CUE/BIN in Dosbox -0.74-2 from Debian repo (version 10.10) and it worked fine for me .

Same here, but without success.

Make sure the directory holding the bin/cue files is both executable and readable by the current user.

I've made sure earlier the directories are readable, but I had no idea, they have to be executable as well. I just tested it.
It works!

It made me wonder, why this is only an issue for the CUE/BIN mounting only. But for now, I already added modified everything in recursive to be executable. I'll try my other images as well.
Thanks!

DBob wrote on 2021-07-03, 19:26:

Yes, it is. […]
Show full quote

Is SDL_Sound actually found and compiled in?

Yes, it is.

And if, is this SDL_Sound compiled against SDL 1.2x?

I don't know. How can I check it?

EDIT : Also, what distro are you using ? I just tested mounting a CUE/BIN in Dosbox -0.74-2 from Debian repo (version 10.10) and it worked fine for me .

Same here, but without success.

Make sure the directory holding the bin/cue files is both executable and readable by the current user.

I've made sure earlier the directories are readable, but I had no idea, they have to be executable as well. I just tested it.
It works!

It made me wonder, why this is only an issue for the CUE/BIN mounting only. But for now, I already added modified everything in recursive to be executable. I'll try my other images as well.
Thanks!

Glad it worked .

Execute permissions are required on a directory in order for access to the files contained in it to be allowed . It's still a bit strange that you were hitting the "MSCDEX: Failure: Invalid file or unable to open." error as having "FILE "XEEN1.IMG" BINARY" being set in your cue files implies that that the XEEN1.IMG is in the same directory as the CUE file and if that directory's permissions were not set to allow execution for the user running DOSBox, the CUE file would not have been readable, which would give a different error message .

I tried reproducing the issue that you mentioned using even the latest SVN build, but am unable to do so (see below). So either there is something different between your setup and mine or there is some misunderstanding as to what was occurring on your end.

Without exec permission on directory :

With exec permission on directory :