Troubleshooting

Connection parameters

If MooseFS Windows® Client is correctly connected to the cluster, a new drive letter should appear in the system. Also, during the connection, a special file system object is created. This object is not visible from the system, but can be read as a regular file from PowerShell or the command line. This object is called .params and can help you view current connection parameters. To read this object contents, type the command in PowerShell: cat M:\.params. The output should look similar to the following example output:

PS C:\Users\tt> cat m:\.params
MASTER_HOST: mfsmaser.mfs.lan
MASTER_PORT: 9421
MASTER_BIND: ( EMPTY )
MASTER_PATH: /
MASTER_PASSWORD: ( **** )
MOUNT_POINT: M:
PREFERRED_LABELS: ( EMPTY )
READ_CACHE_MB: 100
WRITE_CACHE_MB: 128
IO_TRY_CNT: 30
IO_TIMEOUT: 0
MIN_LOG_ENTRY: 5
READAHEAD_LENG: 2097152
READAHEAD_TRIGGER: 20971520
ERROR_ON_LOST_CHUNK: 0
ERROR_ON_NO_SPACE: 0
UID2SID: LDAP
LDAP_HOST:
LDAP_PORT: 0
LDAP_USER_DN: ( EMPTY )
LDAP_USER_PASS: ( EMPTY )
LDAP_BASE_DN: DC=mfs,DC=lan
MFSIO Version: 4.43.0-pro (build 1593)
MooseFS Windows Client Version: 0.10.1

For Command prompt use this command: type M:\.params

MooseFS Operations Log

The MooseFS Windows® Client logs each operation performed on the Client inside a special file system object. This log is very useful for any kind of debugging of Client behaviour. For example, undesirable application behaviour or debugging application performance. Thanks to the operation log, we can easily trace what is happening on the MooseFS Windows® client side.

The special file system object is named .oplog and can be opened from PowerShell as in the example:

cat M:\.oplog

The output is constantly updated. To stop it, press Ctrl+C.

12.13 16:57:06.122: uid:10010 gid:10010 pid:3620 cmd:open_file path:/desktop.ini status:No such file or directory
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:0 status:OK
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:1 status:OK
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:1 status:OK
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:1 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:0 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:1 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:0 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:read_directory path:/ fd:1 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:1 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:0 status:OK
12.13 16:57:06.125: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:0 status:OK
12.13 16:57:06.126: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.126: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.126: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:1 status:OK
12.13 16:57:06.126: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:1 status:OK
12.13 16:57:06.127: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:1 status:OK
12.13 16:57:06.204: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:2 status:OK
12.13 16:57:06.205: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:2 status:OK
12.13 16:57:06.205: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:2 status:OK
12.13 16:57:06.217: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:2 status:OK
12.13 16:57:06.218: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:2 status:OK
12.13 16:57:06.218: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:2 status:OK
12.13 16:57:06.218: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:2 status:OK
12.13 16:57:06.218: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:2 status:OK
12.13 16:57:06.482: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:2 status:OK
12.13 16:57:06.483: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:2 status:OK
12.13 16:57:06.483: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:2 status:OK

Time synchronisation

In case a time desynchronisation between Master Server and Windows® Client is detected, you may find a warning from "MooseFS" source in the system Event Log:

Module=MooseFS 
Message=time desync between client and master is higher than a second - 
it might lead to strange atime/mtime behaviour - 
consider time synchronization in your moosefs cluster

This information means that the Windows® machine and the MooseFS master server do not use the same NTP servers or there is no time synchronization between these components.

In a production environment, when all Windows® machines use Active Directory for time synchronisation, it is also a good idea to synchronise all MooseFS components (Master Servers, Chunkservers, Metaloggers, Linux Clients) to the Active Directory clock.

Can't open MooseFS disk

In case MooseFS Windows® Client was able to connect to the cluster and the new drive letter is available in the system, but you cannot open the device, then, first of all, check the Event Log:

Level	    Date and Time	    Source	Event ID	Task Category
Information	13.12.2022 17:54:34	MooseFS	1	        None	Module=MooseFS Message=DokanCreateFileSystem success
Information	13.12.2022 17:54:34	MooseFS	1	        None	Module=MooseFS Message=Mounted
Information	13.12.2022 17:54:34	MooseFS	1	        None	Module=MooseFS Message=Windows client is allowed

If you see these messages, it means the connection has been accepted and the file system has been created on the Windows® machine. Now, check the connection parameters from the PowerShell level by running the command:

cat M:\.params

...
MASTER_PATH: /winmfs
...
MFSIO Version: 4.43.0-pro (build 1593)
MooseFS Windows Client Version: 0.10.1

If you are able to read this object, it means that the client is connected to the MooseFS cluster.

Next, make sure that the currently logged in user has the correct permissions.
To do so, use PowerShell again and list all objects on the MooseFS disk:

PS C:\Users\test> ls m:\
ls : Access to the path 'M:\' is denied.
At line:1 char:1
+ ls m:\
+ ~~~~~~
    + CategoryInfo          : PermissionDenied: (M:\:String) [Get-ChildItem], UnauthorizedAccessException
    + FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

In this example /winmfs subfolder on a MooseFS cluster is accessed. The Active Directory logged in user test has value 10010 assigned to uidNumber and gidNumber in an Active Directory objects tree:

uid=10010
gid=10010

/winmfs folder on MooseFS cluster belongs to a different uid and different gid:

drwxrwx---   2  1000  1000  2.0M Dec 13 15:58  winmfs

That's why MooseFS Windows® Client refuses to access /winmfs share.

The same situation can occur if an Active Directory user does not have uidNumber and gidNumber assigned in AD objects tree.