Hey guys, this is my first post here, but I did not see a more appropriate category for this question. Here goes..

I have a drive NTFS formatted drive mounted in Debian and a script set to make directories via a linux script and cron job. This was running flawlessly till recently, when I started getting 'mkdir: cannot create directory 'dirname': Operation not supported'.

I have been unable to find any help with this issue online. I assume it is a NTFS mount issue. I know it isn't about file size, as the drive it 1TB.

Here is my fstab for reference:

Do you know what the issue is here? Like I said, up until recently I have been able to create seeming unlimited directories here, but it now stops after about 7 - 10 directories have been created?

Thanks!

Hi Josh,

Well it appears to me the same i.e. NTFS mount issue. The error message you mentioned here says that the operation not supported which means that the device is not mounting with an option that is required to perform a particular operation.

For example same will happen if you try to configure ACL on a directory when the device is not mounted with acl option.

Is there any recent changes made to your /etc/fstab directory?

I doubt that it is even creating 7-10 directories because if that is the case then something is wrong between mount and post script run. To verify we can try the following command:

mount | grep /dev/sdb1 (This will tell us the options with which /dev/sdb1 is getting mounted initially

Run the same command and see if there is a change in ouput.

Another thing that I noticed is that there is no , (comma) between ntfs-3g and rw, was it like that from before? Check if you have a previous backup of /etc/fstab.

There must not be a a comma between ntfs-3g and rw. ntfs-3g is the file-system descriptor, rw is a mount option.

1 members found this post helpful.

Hi TobiSGD,

Yes you are right... I was on different track I guess when I wrote ;-) thinking about acl and default option with a comma in between. When you pointed out I realized that there is no comma between file system and the mount options same as ext4 defaults :-)

ok, I ran 'mount | grep /dev/sdb1' and I get:

/dev/sdb1 on /mnt/backupLocation type fuseblk (rw,allow_other,blksize=4096)

So you are saying that having a comma there could make a difference? I did check one of my fstab backups and it did not have a comma either - that was when it was working.

Thanks for your help!

Well no need to put a comma, just check out my conversation with TobiSGD there shouldn't be a comma.

The output of mount | grep /dev/sdb1 looks ok to me. Did you check the space on your NTFS drive? It might be possible that your NTFS drive is full or may be having less space to perform this operation.

I tried the same command for my external NTFS formatted disk and the output is as follows:

/dev/sdb1 on /media/LOCAL DISK type fuseblk (rw,nosuid,allow_other,blksize=4096,default_permissions)

You can try putting these options in /etc/fstab but I don't think so it will make a difference as the output you mentioned looks fine.

ok, well I just ran a 'df -h' on the drive and I have over 900GB of available space, so it should not be a space issue. The odd thing, is that if I restart the server (which i just did), it allows me to create a directory there again. Do you have any other ideas what the problem could be?

Thanks!

The dirname to me suggest that you are trying to create a non-supported name, or other similar task.


Operation not supported.

The operation, though supported in general, is not supported for the requested object or the requested arguments.

But that wouldn't explain why it would work after a reboot?

Well let me clear it first it is all based on assumptions. Can't say for sure because I haven't see any logs.

You mentioned in your first post that it was going on fine for quite a while but when you ran the script (using cron) today it error out saying operation not supported. So it appears that the system was up from quite a while and might be having some memory issues which you were not aware of. When cron ran the script this time it asked for more memory from the server also initiated an excessive I/O request which might have caused a quick dismount and remount of the device as read only because that is the default action take by a system to avoid any harm to the file system.

This is the only scenario that I can think of that a reboot can fix.