mkdir error when creating share


Recommended Posts

unRAID OS Version:

6.0-beta12

 

Description:

Building my first unraid server.  After adding disks to array and starting array, I noticed "Enable user shares" was off.  After enabling that, tried to create my first share, but it failed.  I stopped the array and restarted it, but share creation still failed (after clicking "Add Share" on the share settings page, no share was ever created and no error was produced).  Syslog pasted below.  I noticed on the server terminal the error "mkdir: cannot create directory '/mnt/user/NewShare': No such file or directory".  As a test, I manually performed "mkdir /mnt/user".  Now I can create a share successfully.  Not certain if this was a proper solution, I deleted the "user" directory I created.  I stopped the array, rebooted the server, and started the array.  Now a "/mnt/user" and "/mnt/user0" exists and I can create shares via the webgui.  I wouldn't expect the user to have to reboot or manually create this subdirectory.

 

How to reproduce:

  • Create new array
  • Start array
  • Settings/Global Share Settings/
  • Enable user shares: Yes
  • Shares tab
  • Add Share
  • Enter a name and apply
     

 

Expected results:

 

Share created

 

Actual results:

 

Share not created and no acknowledgement or error.  "mkdir: cannot create directory '/mnt/user/NewShare': No such file or directory" displayed on console.

 

Other information:

 

Jan 13 17:06:40 Tower emhttp: shcmd (26845): mkdir "/mnt/user/NewShare"
Jan 13 17:06:40 Tower emhttp: shcmd: shcmd (26845): exit status: 1
Jan 13 17:06:40 Tower emhttp: shcmd (26846): rm "/boot/config/shares/NewShare.cfg"
Jan 13 17:06:40 Tower emhttp: shcmd (26847): :>/etc/samba/smb-shares.conf
Jan 13 17:06:40 Tower avahi-daemon[595]: Files changed, reloading.
Jan 13 17:06:40 Tower emhttp: Restart SMB...
Jan 13 17:06:40 Tower emhttp: shcmd (26848): killall -HUP smbd
Jan 13 17:06:40 Tower emhttp: shcmd (26849): cp /etc/avahi/services/smb.service- /etc/avahi/services/smb.service
Jan 13 17:06:40 Tower avahi-daemon[595]: Files changed, reloading.
Jan 13 17:06:40 Tower emhttp: shcmd (26850): pidof rpc.mountd &> /dev/null
Jan 13 17:06:40 Tower avahi-daemon[595]: Service group file /services/smb.service changed, reloading.
Jan 13 17:06:40 Tower emhttp: shcmd (26851): /etc/rc.d/rc.atalk status
Jan 13 17:06:40 Tower avahi-daemon[595]: Service "Tower" (/services/smb.service) successfully established.

Link to comment

Hello,

 

Did you ever get a proper resolution for this? I am also setting up a new server, and am noticing this problem.

 

However, when I try to run "mkdir /mnt/user", I just see:

mkdir: cannot create directory âuserâ: File exists

 

If I try to delete the folder, I just get a

rmdir: failed to remove âuser0â: Device or resource busy

 

Why are the permissions different for the files in my /mnt folder?

drwxrwxrwx 2 nobody users 6 Jan 18 06:25 disk1/

d--------- 1 root  root  0 Dec 31  1969 user/

d--------- 1 root  root  0 Dec 31  1969 user0/

 

 

 

For clarity, I just have a 2TB drive in the array, nothing else. Latest beta, 6.0-beta12. Reboot does not fix anything.

 

No parity. Just trying to get this up and running as a test, but it's been hours and I'm close to giving up. If this works fine, I'll put a parity in, and want to start moving content in.

 

Thanks.

 

hades

Link to comment

The /imt/user and /mnt/user0 folders are created automatically by unRAID when the array is started and User shares are enabled as mount points for this view of the file system.  Not sure why you think you should be doing anything with them, and doing so is likely to lead to data loss.

Link to comment

I understand that they *should* be created, and something is there. Regardless, it isn't a folder that I can access. It has permissions:

d---------

 

I cannot CD into it, it says it's not a file, nor a folder. When I create a share, the console just shows:

mkdir: cannot create directory '/mnt/user/SHARENAME

 

where SHARENAME is the name of the share I am trying to create. It looks like there are no permissions to create subfolders in it. However, I can't change the permissions of the folder either.

 

The end result is, I cannot create a share in v6b12.

 

hades

Link to comment

Hades, I did not get a response, but I was able to get the users and users0 created automatically after a reboot.  Did you get the "user exists" message the first time you tried to create the directory, implying the array made it?  I don't endorse the use of mkdir, but mentioned it from my investigation.  I hesitate to make any suggestions as I'm just learning to manage my own array.  When you are logging in at console, are you using root?  If you stop the array, does the /mnt/user directory still exist?

 

itimpi, what should happen and what does happen are not always the same thing.  I think we all agree the mount should be created by unraid, but in my case it wasn't.  I stopped the array after enabling user shares and restarted it and the "user" was not created (as stated in my original post).  It took a reboot of the server to get unraid to create the directory. Hence, the defect report.

Link to comment

I can confirm this is a bug.  The solution doesn't require you to reboot your entire server.  You just need to stop the array and start it again after you've turned user shares on from an off state.  What we may do is simply change how this function works similar to SMB where changing the setting requires you to first stop the array.

Link to comment
  • 4 months later...

I can confirm this happens testing unRAID 6.0 RC3 in Virtualbox too using the "boot from disk and having an usb with licence key plugged " trick.

 

I don't know if this happens on "production" systems on bare metal too.

 

It's not possible to create user shares and the "mkdir: cannot create directory '/mnt/user/NewShare': No such file or directory" is displayed on console.

 

If I stop the array and make a user dir on mnt manually, it is possible to create user shares, BUT they display free space of the boot disk and NOT the free space of the array.

 

If I then stop array and remove user dir in mnt, when I start array again (with or without a reboot), my user shares aren't recreated even if they are present on /boot/config/shares and on \\tower\flash\config\shares too...

 

I hope (but NOT sure...) it's related to the boot trick used to test unRAID in Virtualbox and that all will go fine on bare metal with a "standard usb boot"... can you confirm it?

 

EDIT: added screenshot attachment to best explain... please note how user dir is created differently than diskX ones (not green like diskX... I don't know what's the difference anyway  ???)... I can't cd to it! And neither chmod it! :o

And when I go to add a "Big" user share by web interface... this is the mkdir error displayed.

 

The Big.cfg in flash share config has been created by adding user as dir with manual mkdir, BUT then it share space on boot IDE disk and not from array...  ::)

If I reboot, Big.cfg is still there, BUT no share go on if I don't mkdir user again...  :(

unRAID.jpg.7be5e15e4e73cbbca6f1316d38ddf2c9.jpg

Link to comment

There's some confusion above, I suspect from Windows users, and I do understand it, as I'm an old DOS and Windows user myself.  As a Windows user, you see a file system and folders, and you automatically think you can add sub-folders and files, but Linux is different.  It's just similar enough to be confusing.  In Linux, everything relates to everything else through a folder tree somehow, in ways that often don't make sense to non-Linux users.  For example, drives and partitions are items that look like files and folders, but you can't add files and folders to them.  The CPU and CPU parameters look like files and folders, but you can't write to them or add files and folders to them.

 

The User Share system is an alternative view of the actual file systems on the data and Cache drives.  It uses a tool called FUSE to build this file system and mounts it on an in-memory pseudo folder named /mnt, with the special folder names /mnt/user and /mnt/user0.  The user0 folder tree is a special purpose internal-use form of the user folder.  The fact that unRAID sets them up to manipulate the files and folders under them makes it easy to think of them as ordinary Windows folders, but they aren't!  It's all designed to make it easy for users with Windows experience to work with, but it cannot completely hide its Linux roots.

 

As jonp said, there is a bug here.  The bug in the original post is the fact that it allowed the user to enable User Shares WHILE the array was started.  As he said, it should require you to stop the array first.  It's only at array start that FUSE is loaded, and it's only loaded if the User Shares are enabled.  So when the original poster tried to enable User Shares, FUSE was not loaded, so there was no User Shares support loaded.  Trying to create a user folder could not work, as it would be a normal folder in memory, not a User Share, and lost on reboot.  It was a probably a good thing it was deleted, because it might possibly have blocked User Shares from starting properly.

 

So how should you create a User Share?  User Shares are real folders that are stored on the data drives and/or the Cache drive.  So to create one, you create it (or configure it to be created) at the top level of a data drive or the Cache drive.  When you NEXT start the array, with User Shares enabled, FUSE will find it and build it into the /mnt/user tree, an artificial view of the same files and folders on disk.

Link to comment

The bug in the original post is the fact that it allowed the user to enable User Shares WHILE the array was started.

 

Yes this is fixed in next release (-rc4).

 

Please... read with more attention what I've reported.  :(

 

I have NOT enabled user shares with array started. And even after a reboot (with user shares already actived) the issue described is still there.

 

About RobJ thoughts... he's right, but this is not my case. I'm surely more trained on Windows OSes (I am an IT manager of a distributed network of over 400 workstations and related servers...), BUT I know a bit of Linux too, enough to understand how Linux filesystems work.

 

Mine was only a simple try on a testing (more... virtual!) environment to see how to fix a bug which otherwise I didn't know how to fix.  ::)

 

I think that it is related to bad attributes on how the 'dir' /user is created dinamically by Fuse, since if you look at my screenshots, it is well different from /disk3 and /disk5 that, in fact, works fine (and they are dynamically created too... but I'm not sure if ever by Fuse).

 

When I 'artificially' created /user dir (with similar attributes to /disk3 and /disk5), the web interface was able to create user shares but, obviously, they didn't work correctly because of mapped to boot disk since mine was a real dir!

 

Please note that even dirs created on top level of my disks aren't automatically shared on this test system.

 

If it's related or not to booting from ide disk with the 'usb inserted trick' I still don't know (I would go bare metal in a day or two...), but since there are a lot of people using it on VM systems with similar boot, I think this should be investigated as well.

 

If you need a syslog, just ask for it!  ;)

Link to comment

...

If it's related or not to booting from ide disk with the 'usb inserted trick' I still don't know (I would go bare metal in a day or two...), but since there are a lot of people using it on VM systems with similar boot, I think this should be investigated as well.

...

 

I've gone to bare metal. I can confirm this issue shows only if using hard disk for boot and "inserted usb trick" used by many on VM testing/use.

 

This is what I get on bare metal unRAID:

 

root@unRAID1:/mnt# ls -l
total 0
drwxrwxrwx 3 nobody users 20 Jun  2 20:45 disk3
drwxrwxrwx 2 nobody users  6 Jun  2 20:39 disk5
drwxrwxrwx 2 nobody users  6 Jun  2 20:43 disk7
drwxrwxrwx 1 nobody users 20 Jun  2 20:45 user

 

This is what I get on VM unRAID:

root@unRAIDSym:/mnt# ls -l
[color=blue]/bin/ls: user: No such file or directory[/color]
total 0
drwxrwxrwx 3 nobody users 19 Jun  1 04:02 [glow=green,2,300]disk3[/glow][color=blue][b]/[/b][/color]
drwxrwxrwx 3 nobody users  106 Jun  1 03:23 [glow=green,2,300]disk5[/glow][color=blue][b]/[/b][/color]
[color=blue]d------------[/color] 1 [color=blue]root root[/color]  0 [color=blue]Jan  1  1970[/color] [color=blue]user[b]/[/b][/color]

(highlighed the differences...)

 

It's A LOT different...  :o

 

Strange is that only Fuse go wild in the process, when all the rest of the system go flawlessly...  ???

Link to comment

Looks like you're running unRaid in a VM - can't help with that.  Does this issue happen when running on 'bare metal'?

 

???

...

If it's related or not to booting from ide disk with the 'usb inserted trick' I still don't know (I would go bare metal in a day or two...), but since there are a lot of people using it on VM systems with similar boot, I think this should be investigated as well.

...

 

I've gone to bare metal. I can confirm this issue shows only if using hard disk for boot and "inserted usb trick" used by many on VM testing/use.

 

This is what I get on bare metal unRAID:

 

root@unRAID1:/mnt# ls -l
total 0
drwxrwxrwx 3 nobody users 20 Jun  2 20:45 disk3
drwxrwxrwx 2 nobody users  6 Jun  2 20:39 disk5
drwxrwxrwx 2 nobody users  6 Jun  2 20:43 disk7
drwxrwxrwx 1 nobody users 20 Jun  2 20:45 user

 

This is what I get on VM unRAID:

root@unRAIDSym:/mnt# ls -l
[color=blue]/bin/ls: user: No such file or directory[/color]
total 0
drwxrwxrwx 3 nobody users 19 Jun  1 04:02 [glow=green,2,300]disk3[/glow][color=blue][b]/[/b][/color]
drwxrwxrwx 3 nobody users  106 Jun  1 03:23 [glow=green,2,300]disk5[/glow][color=blue][b]/[/b][/color]
[color=blue]d------------[/color] 1 [color=blue]root root[/color]  0 [color=blue]Jan  1  1970[/color] [color=blue]user[b]/[/b][/color]

(highlighed the differences...)

 

It's A LOT different...  :o

 

Strange is that only Fuse go wild in the process, when all the rest of the system go flawlessly...  ???

 

Link to comment

Tested plop boot manager to boot from USB in Virtualbox as many use it in ESXi with success and so remove the "USB inserted trick" which is creating the issue described in this thread.

 

No cigar.  :'(

 

With USB2.0 support enabled in Virtualbox plop hang on choosing USB as boot drive (known issue).

 

With SHIFT pressed (alternate driver) it stop with error "no hard drive connected to USB".

 

With USB2.0 support disabled, it begins to boot and stop immedately after on "SYSLINUX...". works even if veeery slow boot... but no cigar anyway. See post below.

 

I'll try other methods... and we will see...  ;)

Link to comment

Since having Virtualbox still not supporting USB boot in 2015 (and with an USB support still quite buggy...  ::) ) and having Limetech officially not supporting unRAID on VMs (even if a LOT her are using it at least in ESXi with no or minimal issues), I'm actively working in solving this issue since I really would like to have a 'virtual lab' of my unRAID system where make tests, experiments and so on (I like working this way... I've a Virtualboxed replica of all my AD DC controllers with some clients too... and it's perfectly working & proved to be very usefull sometime! ;)).

 

This issue is officially related to Fuse that seems to go crazy on dinamically creating user shares when array is started and system has been booted from hdd using 'USB inserted trick' for licence and config files.

 

Since fixing Fuse behaviour is out of my 'abilities' (for now...  ;D) I'm concentrating in two different directions:

 

- a boot manager, possibly on a live CD or floppy .img, capable of booting fine from USB, and... it doesn't work.

 

- modifying unRAID syslinux startup commands to make them load bzroot and bzimage from USB even if boot has started from hdd (or CD... Eheheheh...  :P) since this could probably fix the Fuse issue...

 

The first seemed the easier one, BUT with Plop failing and Virtualbox USB support still a bit buggy, I've not still able to find a suitable solution (even SuperGrub live failed... suggestions are appreciated....)

it doesn't solve the issue.

 

So I'm focusing ond second one since syslinux is very powerful... BUT my experience on it is very limited... and I'm asking help to someone more trained than me on it...  ???

 

Since what I've understood, we should try a 'chain boot' with a first syslinux boot (from CD or HDD) that calls a second syslinux boot from USB (the unRAID stock one), OR a way to modify the original bzroot & bzimage load commands to make them pointing to USB instead of CD or HDD.

 

But up to date, I have been able only to get mounting errors & similar...  ::)

(unRAID syslinux sequence seems to be a bit 'advanced' and not so easy to fully understand and modify using syslinux manuals & guides...  :o)

 

Someone (limetech?  bonienl? :D) capable of giving me tips?

Link to comment

At last I was able to load from USB with PLOP and setting USB 2.0 support disabled in Virtualbox... BUT the Fuse issue is still there!  :'(

 

Is there someone which can explain to me ONLY why - this is Linux CLI understanding which lacks to me...   :-\ - when all go fine disk and user dir are showed by ls in plain grey and with no / trailing and when Fuse go crazy (in Virtualbox), disk dirs are highlighted in green, they and user have all a / trailing them and user is showed in blue/violet and no chmod or chown works on this one?

 

This is what I get on bare metal unRAID:

 

root@unRAID1:/mnt# ls -l
total 0
drwxrwxrwx 3 nobody users 20 Jun  2 20:45 disk3
drwxrwxrwx 2 nobody users  6 Jun  2 20:39 disk5
drwxrwxrwx 2 nobody users  6 Jun  2 20:43 disk7
drwxrwxrwx 1 nobody users 20 Jun  2 20:45 user

 

This is what I get on VM unRAID:

root@unRAIDSym:/mnt# ls -l
[color=blue]/bin/ls: user: No such file or directory[/color]
total 0
drwxrwxrwx 3 nobody users 19 Jun  1 04:02 [glow=green,2,300]disk3[/glow][color=blue][b]/[/b][/color]
drwxrwxrwx 3 nobody users  106 Jun  1 03:23 [glow=green,2,300]disk5[/glow][color=blue][b]/[/b][/color]
[color=blue]d------------[/color] 1 [color=blue]root root[/color]  0 [color=blue]Jan  1  1970[/color] [color=blue]user[b]/[/b][/color]

(highlighed the differences...)

 

 

(Screenshot available on page 1 too...)

Link to comment

This is not necessarily a FUSE issue, probably it's not.

 

Please don't take this wrong: we have enough on our plate to get bare-metal unRaid-6 stable, and now you want us to divert resources down a very large rabbit hole of debugging unRaid as a guest in your VM?  I'm sorry we simply can't do that right now.  I hope you understand.

Link to comment

I can understand very well your point. In fact this should now probably moved to 'General support' or 'unRAID on VMs' to continue discussion...  ;)

 

When I opened this at first I still wasn't sure unRAID would have worked fine on bare metal.

 

Anyway, I'm interested in studing this since it is a strange behaviour and I would like to understand it for my own knowledge. I work this way. Ever.  :D

 

If someone would have tips for me... will be the welcome!  :)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.